Details
-
New Feature
-
Status: In Review (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
Hi,
I have a workflow that need a user input at some stage.
However, due to the frequent commits, which trigger the builds, I get to the case when I have several builds of the same workflow stay idle in the list awaiting the user input.
I would expectr my workflow to discard older builds if the newer build has reached the same stage.
But I cannot succeed that goal.
If I use the workflow like:
stage title: 'DevBuild', concurrency: 1 // do build stage title: 'Integration', concurrency: 1 input message: 'Proceed?' // do integration
then the very first build enters 'Integration' stage and pauses for user input. The other newer builds may superseed each other, but there is always the last build that gets to 'Integration' stage and waits until the very first build completes (because it cannot enter stage Integration).
I would like the newer build to discard the older build which waits for user input in this case, so that newer build can be decided by the user.
Is it possible to implement such a scenario?
Thank you
Attachments
Issue Links
- is related to
-
JENKINS-32829 Older builds allowed to wait for a throttled stage which a newer build is in
-
- Closed
-
-
-
- Resolved
-
-
-
- Resolved
-
- links to
Activity
chrisleck yes there has been some thought on that (cc hrmpw abayer) - some alternative way of expressing input. However, there is no getting around if you want to wait for input and not eat a node, you need to do "work" to ensure you stash and unstash things, which can never really be transparent, as magic isn't real. I wish it was.
Looking at the stock demo (I think this is it)
https://github.com/jenkinsci/workflow-aggregator-plugin/blob/60d8ea3/demo/repo/Jenkinsfile
there seems to be problem for this use case.
The input step in the Staging stage is holding onto the 'staging-server' lock, which means later builds won't proceed until someone tells the input step to Proceed, or cancels the build. (EDIT: I confirmed this behaviour using the docker-based demo.)
In some cases this is what you want, but if you want the input step to cancel older executions (as suggested by the issue title and description), this won't happen. I suppose you would have to do something like this: https://github.com/cloudbees/jenkins-scripts/blob/master/cancel-builds-same-job.groovy
(Also, I think the milestone 3 should be inside a lock, otherwise I suspect a race condition could lead to older builds being deployed into production after newer builds.)
Sean Flanigan
added a comment - - edited Looking at the stock demo (I think this is it)
https://github.com/jenkinsci/workflow-aggregator-plugin/blob/60d8ea3/demo/repo/Jenkinsfile
there seems to be problem for this use case.
The input step in the Staging stage is holding onto the 'staging-server' lock, which means later builds won't proceed until someone tells the input step to Proceed, or cancels the build. (EDIT: I confirmed this behaviour using the docker-based demo.)
In some cases this is what you want, but if you want the input step to cancel older executions (as suggested by the issue title and description), this won't happen. I suppose you would have to do something like this: https://github.com/cloudbees/jenkins-scripts/blob/master/cancel-builds-same-job.groovy
(Also, I think the milestone 3 should be inside a lock , otherwise I suspect a race condition could lead to older builds being deployed into production after newer builds.) seanf is correct, with current tools the best you can do is have multiple commit's waiting for input, then use milestones so if the latest is approved the previous ones will fail... but only if their own input blocks get interacted with after.
A lock will prevent a newer build from entering an input step, and a milestone can only take affect before or after an input step, but multiple input steps can all be reached and idle at the same time requiring input. Can we make input work like a milestone, failing previouos ones? And why is this marked Resolved when the case in the original post was not handled?
This arguably makes the input step dangerous for declarative pipeline users...is there a way to make this experience better for users out of the box?