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

Option for input or stage step to cancel older executions

    XMLWordPrintable

Details

    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

            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?

            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?
            michaelneale Michael Neale added a comment -

            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.

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

            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.)
            jglick Jesse Glick added a comment -

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

            jglick Jesse Glick added a comment - Not sure offhand. Would have to spend a day studying it.
            ironsean Sean MacKay added a comment -

            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?

            ironsean Sean MacKay added a comment - 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?

            People

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

              Dates

                Created:
                Updated:
                Resolved: