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

"Unable to find a build" when using DownstreamBuildSelector with Jenkins Pipelines

XMLWordPrintable

      Given two basic Jenkins Pipelines:

      //Pipeline 'a'

      stage 'stage'
    node{
        build 'b'
        step([$class: 'CopyArtifact', projectName: 'b', selector: [$class: 'DownstreamBuildSelector', upstreamBuildNumber: env.BUILD_NUMBER, upstreamProjectName: env.JOB_NAME]])
    }

      //Pipeline 'b'

      stage 'stage'
    node{
        writeFile file: 'target/b.txt', text: 'b'
        archive includes:'target/b.txt'
    }

      Copy artifact cannot find the right build from the Pipeline, consistently returning:

      ERROR: Unable to find a build for artifact copy from: b
      Finished: FAILURE

      It doesn't work when removing the env.XYZ variables and passing in hard-coded values either.

          [JENKINS-33577] "Unable to find a build" when using DownstreamBuildSelector with Jenkins Pipelines

          Andy Pemberton created issue -
          Andy Pemberton made changes -
          Description Original: Given two very basic Jenkins Pipelines:

          //Pipeline 'a'

          {code:java}
          stage 'stage'
              node{
                  build 'b'
                  step([$class: 'CopyArtifact', projectName: 'b', selector: [$class: 'DownstreamBuildSelector', upstreamBuildNumber: env.BUILD_NUMBER, upstreamProjectName: env.JOB_NAME]])
              }
          {code}


          //Pipeline 'b'

          {code:java}
          stage 'stage'
              node{
                  writeFile file: 'target/b.txt', text: 'b'
                  archive includes:'target/b.txt'
              }
          {code}

          Copy artifact cannot find the right build from the Pipeline, consistently returning:

          ERROR: Unable to find a build for artifact copy from: b
          Finished: FAILURE

          It doesn't work when removing the env.XYZ variables and passing in hard-coded values either.
          		 New: Given two basic Jenkins Pipelines:

          //Pipeline 'a'

          {code:java}
          stage 'stage'
              node{
                  build 'b'
                  step([$class: 'CopyArtifact', projectName: 'b', selector: [$class: 'DownstreamBuildSelector', upstreamBuildNumber: env.BUILD_NUMBER, upstreamProjectName: env.JOB_NAME]])
              }
          {code}


          //Pipeline 'b'

          {code:java}
          stage 'stage'
              node{
                  writeFile file: 'target/b.txt', text: 'b'
                  archive includes:'target/b.txt'
              }
          {code}

          Copy artifact cannot find the right build from the Pipeline, consistently returning:

          ERROR: Unable to find a build for artifact copy from: b
          Finished: FAILURE

          It doesn't work when removing the env.XYZ variables and passing in hard-coded values either.
          Jesse Glick made changes -
          Labels New: workflow

          Jesse Glick added a comment -

          Probably not a defect at all. Builds run with the build step are not considered “downstream”, and probably would not be even with JENKINS-29913, since the dependency graph is static. So DownstreamBuildSelector makes no sense in this context, and this is already logged.

          I think you just want to use SpecificBuildSelector. And you need to save the return value of the build step so you can access its .number.

          Jesse Glick added a comment - Probably not a defect at all. Builds run with the build step are not considered “downstream”, and probably would not be even with JENKINS-29913 , since the dependency graph is static. So DownstreamBuildSelector makes no sense in this context, and this is already logged . I think you just want to use SpecificBuildSelector . And you need to save the return value of the build step so you can access its .number .

          Andy Pemberton added a comment - - edited

          jglick strange. Using the 'build' DSL syntax does log the following:

          Started by upstream project "HyperLynxAS/units/HyperLynxAS/Common" build number 277

          And I do see the following in the build.xml:

              <hudson.model.CauseAction>
      <causes>
        <hudson.model.Cause_-UpstreamCause>
          <upstreamProject>a</upstreamProject>
          <upstreamUrl>job/a</upstreamUrl>
          <upstreamBuild>286</upstreamBuild>
          <upstreamCauses>
            <hudson.model.Cause_-UserIdCause/>
          </upstreamCauses>
        </hudson.model.Cause_-UpstreamCause>
      </causes>
    </hudson.model.CauseAction>

          Is this really not considered "downstream"? Yes - I also tried SpecificBuildSelector and while that may work in my scenario, my downstream jobs are called recursively, making passing specific build numbers much more challenging.

          Andy Pemberton added a comment - - edited jglick strange. Using the 'build' DSL syntax does log the following: Started by upstream project "HyperLynxAS/units/HyperLynxAS/Common" build number 277 And I do see the following in the build.xml: <hudson.model.CauseAction> <causes> <hudson.model.Cause_-UpstreamCause> <upstreamProject> a </upstreamProject> <upstreamUrl> job/a </upstreamUrl> <upstreamBuild> 286 </upstreamBuild> <upstreamCauses> <hudson.model.Cause_-UserIdCause/> </upstreamCauses> </hudson.model.Cause_-UpstreamCause> </causes> </hudson.model.CauseAction> Is this really not considered "downstream"? Yes - I also tried SpecificBuildSelector and while that may work in my scenario, my downstream jobs are called recursively, making passing specific build numbers much more challenging.
          Jesse Glick made changes -
          Remote Link New: This issue links to "PR 80 (Web Link)" [ 14078 ]

          Jesse Glick added a comment -

          apemberton from the perspective of the downstream build there is indeed an UpstreamCause. But the upstream/downstream relationships are specific to AbstractProject. UpstreamCause is only considered by TriggeredBuildSelector, which is in the wrong direction for this use case.

          Anyway as the PR demonstrates, SpecificBuildSelector is all you need, and is much more straightforward and reliable than trying to make Jenkins infer the right build number: you have it right in front of you.

          Jesse Glick added a comment - apemberton from the perspective of the downstream build there is indeed an UpstreamCause . But the upstream/downstream relationships are specific to AbstractProject . UpstreamCause is only considered by TriggeredBuildSelector , which is in the wrong direction for this use case. Anyway as the PR demonstrates, SpecificBuildSelector is all you need, and is much more straightforward and reliable than trying to make Jenkins infer the right build number: you have it right in front of you.

          Jesse Glick added a comment -

          Really from Pipeline I would advocate only using SpecificBuildSelector, and where we need to introduce general-purpose Pipeline tools to introspect related projects & builds, like JENKINS-31576, we can do that.

          Jesse Glick added a comment - Really from Pipeline I would advocate only using SpecificBuildSelector , and where we need to introduce general-purpose Pipeline tools to introspect related projects & builds, like JENKINS-31576 , we can do that.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-31576 [ JENKINS-31576 ]
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-29913 [ JENKINS-29913 ]

            Unassigned Unassigned
            apemberton Andy Pemberton
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: