| I encountered this problem independently. The existing description seems accurate enough. I am providing a new test case to reproduce. It should take less than 15 minutes. See below, with attachments as noted. Jenkins 2.176.1 Promoted Builds Plugin 3.2 (downgraded from 3.3 because JENKINS-58337) Copy Artifacts Plugin 1.42.1 Steps to reproduce
- Create a new freestyle job with
- 1 manual promotion including a copy artifacts step (a-JobConfig-1)
- 1 archived artifact (b-JobConfig-2)
- Run two builds
- Manually promote the second build
- (d-PromoteSecondBuildFirst, e-PromoteSecondBuildFirst-console)
- Manually promote the first build
- (f-PromoteFirstBuildLast, g-PromoteFirstBuildLast-console)
The log of the first build's promotion (g-PromoteFirstBuildLast-console) shows that the second build actually got promoted. Fortunately, there is a workaround for this bug that meets my requirements. Instead of specifying "Which build" as "Specified by Permalink" with Permalink = <the Name of this Promotion Process>, I now use "Specific build" with build number = "${PROMOTED_NUMBER}" Since this build selection method seems to do the job, and the "Permalink -> <the Promotion Process name>" build selection method can be misleading, perhaps it makes sense to remove the "Permalink -> <the Promotion Process name>" build selection method from CopyArtifacts. |
