The downstream job may be triggered from the upstream job by calling the build step. In this case, it doesn't make sense to use the last stable build from the upstream job.

      The downstream job should use the CauseAction to get the reference to the upstream job.

          [JENKINS-36152] Reference the upstream job by using CauseAction

          Jesse Glick added a comment -

          As noted elsewhere, I do not really recommend relying on UpstreamCause, which was mainly intended as informational (for human display), not an authoritative source.

          Better IMO for the upstream build to name a particular workspace somehow, and pass this information as a parameter to the downstream build. Explicit, debuggable, safe for concurrent use.

          Jesse Glick added a comment - As noted elsewhere, I do not really recommend relying on UpstreamCause , which was mainly intended as informational (for human display), not an authoritative source. Better IMO for the upstream build to name a particular workspace somehow, and pass this information as a parameter to the downstream build. Explicit, debuggable, safe for concurrent use.

          Oleg Nenashev added a comment -

          Yep, good subject for discussion. Ideally the plugin could have a WorkspaceSelector extension point with different implementations.
          Unique IDs would be neat for Fingerprinting feature BTW.

          Oleg Nenashev added a comment - Yep, good subject for discussion. Ideally the plugin could have a WorkspaceSelector extension point with different implementations. Unique IDs would be neat for Fingerprinting feature BTW.

          Resolved with JENKINS-36742

          Alexandru Somai added a comment - Resolved with JENKINS-36742

            alexsomai Alexandru Somai
            alexsomai Alexandru Somai
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: