Jenkins-workflow - promotion stage (a better solution than "input")? - jenkins-workflow

Question

We started using jenkins-workflow to manage our Continuous Delivery pipeline.
Here is a simple Pipeline example of what we are doing:
[Build project] => [Run unit tests] => [Run integration tests] => [QA Promotion] => [Deploy in QA] => [UAT Promotion] => [Deploy in UAT]
Where:
[QA Promotion] and [UAT Promotion] are stages waiting for someone to "promote" the build (implemented with the "input" step).
This is purely esthetic, but one thing we found not really nice was that every builds that are waiting at a promotion stage are displayed as "in progress" (with the progress bar indefinitely running). This is weird because if the last 10 builds were not deployed in QA, then we are ending having 10 builds displayed as "running".
I know that waiting for an input will not cause any performance issue. Since if these input steps are not encapsulated inside a node, then they are only consuming flyweight executors (an uncounted slot that is assumed to not take any significant computational power, src: https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md).
So, I was wondering if it exists a better solution that would allow us "promoting" builds with the Jenkins Pipeline without the esthetic inconvenience described above.
Thank you

Answer 1

The milestone plugin is available here: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Milestone+Step+Plugin
What it does:
By default, Pipeline builds can run concurrently. The milestone step ensures an older build will not override a newer build, so the older build will never be allowed to pass a milestone (it is aborted) if a newer build already passed it.
This step is specially useful in Continuous Delivery pipelines, where builds ordering is very important as the order defines what is going to be delivered, so it provides a control point that aborts any build trying to deliver an old commit when a newer one is already being delivered.
In general this step grants:
Builds pass milestones in order (taking the build number as sorter field).
Older builds will not proceed (they are aborted) if a newer one already passed the milestone.
When a build passes a milestone, any older build that passed the previous milestone but not this one is aborted (see TIP 2 below).
The major downside is that it doesn't allow you to promote older builds, and you do still end up with lots of jobs "stuck waiting".

Answer 2

if the last 10 builds were not deployed in QA, then we are ending having 10 builds displayed as "running"
The concurrency argument to stage was designed for this kind of purpose. It does not quite work the way you want in conjunction with things like input, which is why a milestone step is in testing.

Answer 3

If you want to clean up the pipeline you can use timeouts on your inputs
timeout(time:1, unit:'DAYS') {
input message:'Approve deployment?'
}