Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-24626

Parameter values of build selector change when upgrading CopyArtifact

      Hi,

      We have a problem when passing Build selector for Copy Artifact as a parameter filter for an older job/build.

      Suppose 3 Jobs:

      • Job 1: DepJob
      • Job 2: SubJob
        • Build selector for Copy Artifact Parameter: SELECT_ME
          • Default selector : Specific build
          • Build number : 123
        • Build step: Copy artifacts from another project:
          • Project Name : DepJob
          • Which build : Specified by a build parameter
            • Parameter Name : SELECT_ME
      • Job 3: MainJob
        • Build selector for Copy Artifact Parameter: SELECT_DEPJOB
          • Default selector : Specific build
          • Build number : 123
        • Build step: Copy artifacts from another project:
          • Project Name : SubJob
          • Which build : Latest successful build
          • Parameter filters : SELECT_ME=$SELECT_DEPJOB

      Quick issue description

      When last successful build of SubJob has been built with an older version of the Copy Artifact Plugin, then MainJob cannot find the artifacts although they exist!

      Details

      1. DepJob has a build 123.
      2. SubJob performs some builds with Copy Artifact Plugin version 1.26:
        • Build selector for Copy Artifact Parameter:
          • SELECT_ME: Specific build -> 123
      3. Update Copy Artifact Plugin
      4. MainJob performs build with Copy Artifact Plugin version 1.31:
        • Build selector for Copy Artifact Parameter:
          • SELECT_DEPJOB: Specific build -> 123
      5. MainJob build fails since it cannot find atifacts with SELECT_ME: Specific build -> 123 in the old builds of SubJob!

      This is a blocker for us since we have a very large project which uses this kind of constructions for packaging all sub-projects (aka sub jobs).

      We recently updated the Copy Artifact Plugin, but we still need lots of artifacts the old(er) sub-projects (for which currently no rebuilt is needed).

          [JENKINS-24626] Parameter values of build selector change when upgrading CopyArtifact

          Tom Ghyselinck created issue -
          Tom Ghyselinck made changes -
          Affects Version/s New: current [ 10162 ]

          Daniel Beck added a comment -

          Regarding the blocker priority, can't you just downgrade the plugin?

          Daniel Beck added a comment - Regarding the blocker priority, can't you just downgrade the plugin?

          Hi Daniel,

          Thank you for the quick reply.

          Yes, we could do so, but meanwhile we also have
          a lot of builds which used the newer Copy Artifact Plugin.

          We also need some bug fixes and features from the new version.

          Maybe it's quite easy to disable the version check
          or to add some backward compatibility?

          Thank you in advance!

          Tom Ghyselinck added a comment - Hi Daniel, Thank you for the quick reply. Yes, we could do so, but meanwhile we also have a lot of builds which used the newer Copy Artifact Plugin . We also need some bug fixes and features from the new version. Maybe it's quite easy to disable the version check or to add some backward compatibility? Thank you in advance!

          ikedam added a comment -

          Let me know:

          • Does SubJob work fine after upgrading copyartifact to 1.31?
          • Did MainJob work fine before upgrading copyartifact to 1.31?

          And could you attach following files?

          • configurations of those jobs. They are placed at ${JENKINS_HOME}/jobs/(jobname)/config.xml
          • console outputs for a succeeded build and a failed build.

          ikedam added a comment - Let me know: Does SubJob work fine after upgrading copyartifact to 1.31? Did MainJob work fine before upgrading copyartifact to 1.31? And could you attach following files? configurations of those jobs. They are placed at ${JENKINS_HOME}/jobs/(jobname)/config.xml console outputs for a succeeded build and a failed build.

          ikedam added a comment -

          I found the root cause.
          It is caused for SELECT_ME=$SELECT_DEPJOB does not work.

          A build of SubJob with copyartifact 1.26 is recorded like this (see recorded with plugin="copyartifact@1.26"):

              <hudson.model.ParametersAction>
                <parameters>
                  <hudson.model.StringParameterValue>
                    <name>SELECT_ME</name>
                    <description></description>
                    <value>&lt;SpecificBuildSelector plugin=&quot;copyartifact@1.26&quot;&gt;  &lt;buildNumber&gt;1&lt;/buildNumber&gt;&lt;/SpecificBuildSelector&gt;</value>
                  </hudson.model.StringParameterValue>
                </parameters>
              </hudson.model.ParametersAction>
          

          When running MainJob is started with copyartifact 1.31, the build is launched like this (see recorded with plugin="copyartifact@1.31"):

              <hudson.model.ParametersAction>
                <parameters>
                  <hudson.model.StringParameterValue>
                    <name>SELECT_DEPJOB</name>
                    <description></description>
                    <value>&lt;SpecificBuildSelector plugin=&quot;copyartifact@1.31&quot;&gt;  &lt;buildNumber&gt;1&lt;/buildNumber&gt;&lt;/SpecificBuildSelector&gt;</value>
                  </hudson.model.StringParameterValue>
                </parameters>
              </hudson.model.ParametersAction>
          

          And they doesn't satisfy SELECT_ME=$SELECT_DEPJOB.

          As that serialization is the work of Jenkins core (or Jenkins framework), and I'm not sure I can fix that.
          I think we should consider an alternate way to do what @tom_ghyselinck want to do.

          ikedam added a comment - I found the root cause. It is caused for SELECT_ME=$SELECT_DEPJOB does not work. A build of SubJob with copyartifact 1.26 is recorded like this (see recorded with plugin="copyartifact@1.26"): <hudson.model.ParametersAction> <parameters> <hudson.model.StringParameterValue> <name>SELECT_ME</name> <description></description> <value>&lt;SpecificBuildSelector plugin=&quot;copyartifact@1.26&quot;&gt; &lt;buildNumber&gt;1&lt;/buildNumber&gt;&lt;/SpecificBuildSelector&gt;</value> </hudson.model.StringParameterValue> </parameters> </hudson.model.ParametersAction> When running MainJob is started with copyartifact 1.31, the build is launched like this (see recorded with plugin="copyartifact@1.31"): <hudson.model.ParametersAction> <parameters> <hudson.model.StringParameterValue> <name>SELECT_DEPJOB</name> <description></description> <value>&lt;SpecificBuildSelector plugin=&quot;copyartifact@1.31&quot;&gt; &lt;buildNumber&gt;1&lt;/buildNumber&gt;&lt;/SpecificBuildSelector&gt;</value> </hudson.model.StringParameterValue> </parameters> </hudson.model.ParametersAction> And they doesn't satisfy SELECT_ME=$SELECT_DEPJOB . As that serialization is the work of Jenkins core (or Jenkins framework), and I'm not sure I can fix that. I think we should consider an alternate way to do what @tom_ghyselinck want to do.

          ikedam added a comment -

          Updated the summary

          ikedam added a comment - Updated the summary
          ikedam made changes -
          Summary Original: Unable to CopyArtifact from builds using older CopyArtifact plugin New: Parameter values of build selector change when upgrading CopyArtifact

          Hi ikedam,

          Thank you for the update!

          I would be great if you can find a workaround or an alternative way for it!

          Is it an option to provide the values string-based instead of xml-based?
          Using custom encoder / decoder? Or provide a custom dumper which does not add the version info?

          This would allow for some backward compatibility.

          Tom Ghyselinck added a comment - Hi ikedam , Thank you for the update! I would be great if you can find a workaround or an alternative way for it! Is it an option to provide the values string-based instead of xml-based ? Using custom encoder / decoder? Or provide a custom dumper which does not add the version info? This would allow for some backward compatibility.

          ikedam added a comment -

          Though I believe I can remove "plugin" attribute by overwiting XStream2#createDefaultConverter, that's not a good approach as it might cause copyartifact stop working in a future version of Jenkins.
          https://github.com/jenkinsci/jenkins/blob/jenkins-1.565.1/core/src/main/java/hudson/util/XStream2.java#L122

          Rather, I'm considering adding a new build selector "Downstream of". You can pick the build like this:

          • Which build: Downstream of
          • Upstream project: DepJob
          • Upstream build #: 123
          • Target Downstream Project: MainJob

          ikedam added a comment - Though I believe I can remove "plugin" attribute by overwiting XStream2#createDefaultConverter , that's not a good approach as it might cause copyartifact stop working in a future version of Jenkins. https://github.com/jenkinsci/jenkins/blob/jenkins-1.565.1/core/src/main/java/hudson/util/XStream2.java#L122 Rather, I'm considering adding a new build selector "Downstream of". You can pick the build like this: Which build: Downstream of Upstream project: DepJob Upstream build #: 123 Target Downstream Project: MainJob

            ikedam ikedam
            tom_ghyselinck Tom Ghyselinck
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: