[FIXED JENKINS-16213] Add global and local settings to promote newest or oldest build

[karisivo]

JENKINS-16213

There are jenkins ticket for copyArtifact plugin JENKINS-11655, where blamed that plugin copy wrong artifacts. I didn't finad any similar issue for Build Promotion plugin, even it have the same problem. When there are used "Downsteam trigger" in promotion criteria, and downstream build is started by more than one build, first build is promoted when job is done. In this change latest build is promoted.

BUT, if you are using Copy Artifact plugin in downstream job, job where Artifacts are copied will be promoted.
There is need to fix this issue in Copy Artifact plugin to get it work also like this promotion plugin.

[cloudbees-pull-request-builder]

plugins » promoted-builds-plugin #52 SUCCESS
This pull request looks good

[jenkinsadmin]

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

[karisivo]

Now there is more clever solution. Solution copied from CopyArtifact plugin. There is now global settings default UseOldest. And there is also job configuration default UseGlobal. So behaiviour will stay as it was earlier. Behaiviour is easy to change from one global settings.

[jglick]

As written in JIRA, I am dubious that this approach is right. Possibly stems from a misunderstanding of how downstream promotions are supposed to work. Admittedly using the Promoted Builds plugin correctly is notoriously hard (pupils in Jenkins training repeatedly stumble over it), which was one of my motivations in the design of the Workflow plugin. At any rate, DownstreamPassCondition already has two modes of operation: first it looks for true upstream builds based on fingerprints; failing that, it uses the PseudoDownstreamBuilds action to find an upstream build based on UpstreamCause.

Also PRs without tests are usually pushed to the back burner. In this case it looks like PromotionProcessTest.testPromotionWithoutFingerprint is supposed to be testing that DownstreamPassCondition works in its fallback mode, but the test may not be checking enough variations. The helpfully-named test1 may be testing the primary mode with fingerprints.

(Also as a rule we do not want plugins adding global configuration options for things which can anyway be changed on a per-job basis. There are several job templating plugins available which can be used to avoid duplication.)

By the way this plugin has no permanent maintainer that I know of.

[dnozay]

I'm not the current maintainer of the plugin, but let me chip in. There is insufficient info in JENKINS-16213 to conclude what exactly is the problem. Are there any quiet period attached to the projects, or is that happening all the time; what constitutes triggering two builds in a short time? It would be much easier to deal with this issue if someone contributed a testcase uncovering the issue.

[oleg-nenashev]

The fix smells to be the error-prome

@karisivo
Any plans to work on it according to comments?