Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27039

Option for input or stage step to cancel older executions

    Details

    • Similar Issues:

      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

            Activity

            Hide
            ironsean Sean MacKay added a comment -

            Sean Flanigan 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?

            Show
            ironsean Sean MacKay added a comment - Sean Flanigan 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?
            Hide
            jglick Jesse Glick added a comment -

            Not sure offhand. Would have to spend a day studying it.

            Show
            jglick Jesse Glick added a comment - Not sure offhand. Would have to spend a day studying it.
            Hide
            seanf 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.)

            Show
            seanf 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.)
            Hide
            michaelneale Michael Neale added a comment -

            Christopher Eck yes there has been some thought on that (cc Patrick Wolf Andrew Bayer) - 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.

            Show
            michaelneale Michael Neale added a comment - Christopher Eck yes there has been some thought on that (cc Patrick Wolf Andrew Bayer ) - 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.
            Hide
            chrisleck Christopher Eck added a comment -

            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?

            Show
            chrisleck Christopher Eck added a comment - 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?

              People

              • Assignee:
                amuniz Antonio Muñiz
                Reporter:
                ykryshchuk Yuriy Kryshchuk
              • Votes:
                27 Vote for this issue
                Watchers:
                45 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: