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

Option for input or stage step to cancel older executions

      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

          [JENKINS-27039] Option for input or stage step to cancel older executions

          Michael Neale added a comment -

          Re-opening as neither myself or anyone I know has observed this behavior. This may be a bug vs a feature request.

          To reproduce: open a PR, let it start building, push an update to the PR, note that there will be 2 concurrent pipeline runs.

          Michael Neale added a comment - Re-opening as neither myself or anyone I know has observed this behavior. This may be a bug vs a feature request. To reproduce: open a PR, let it start building, push an update to the PR, note that there will be 2 concurrent pipeline runs.

          Unless I'm missing something, I don't believe this feature/plugin addresses the original request?

          Imagine my pipeline looks like:
          ...
          milestone 100
          input "Should I proceed?
          milestone 200
          ...

          Commit A for my master branch comes along, the pipeline runs, and I hang waiting on the input.
          Commit B comes up 30 minutes later, runs through the pipeline, and is now hung waiting on the input.

          With a busy master branch, this ends up wasting a lot of nodes as each input step sits on the node it's running on.

          Ideally, I would mark the input with a milestone tag (or something similar) such that when commit B gets to the input, commit A is aborted automatically.

          Christopher Eck added a comment - Unless I'm missing something, I don't believe this feature/plugin addresses the original request? Imagine my pipeline looks like: ... milestone 100 input "Should I proceed? milestone 200 ... Commit A for my master branch comes along, the pipeline runs, and I hang waiting on the input. Commit B comes up 30 minutes later, runs through the pipeline, and is now hung waiting on the input. With a busy master branch, this ends up wasting a lot of nodes as each input step sits on the node it's running on. Ideally, I would mark the input with a milestone tag (or something similar) such that when commit B gets to the input, commit A is aborted automatically.

          Jesse Glick added a comment -

          See the stock demo for recommended usage, and please do not reopen.

          Jesse Glick added a comment - See the stock demo for recommended usage, and please do not reopen.

          Jesse Glick added a comment -

          do you mean running PR build in multibranch should abort if new build for same PR is scheduled?

          Not unless you use milestone. What I meant was that

          not cancel any builds for a different PR

          is irrelevant for multibranch folders, since each PR is its own job, and milestone only pays attention to builds of the current job.

          Jesse Glick added a comment - do you mean running PR build in multibranch should abort if new build for same PR is scheduled? Not unless you use milestone . What I meant was that not cancel any builds for a different PR is irrelevant for multibranch folders, since each PR is its own job, and milestone only pays attention to builds of the current job.

          Jesse Glick added a comment -

          such that when commit B gets to the input, commit A is aborted automatically

          This is another possible option for milestone, not currently supported. The initial implementation covers the case that A, B, C, …, M are waiting; when you approve (or reject) A, B…L will be stopped in favor of M, but we are guaranteed to make progress.

          this ends up wasting a lot of nodes as each input step sits on the node it's running on

          Then do not run input inside a node block. See the docs for stash.

          Jesse Glick added a comment - such that when commit B gets to the input, commit A is aborted automatically This is another possible option for milestone , not currently supported. The initial implementation covers the case that A, B, C, …, M are waiting; when you approve (or reject) A, B…L will be stopped in favor of M, but we are guaranteed to make progress. this ends up wasting a lot of nodes as each input step sits on the node it's running on Then do not run input inside a node block. See the docs for stash .

          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?

          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?

          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.

          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.

          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.)

          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.)

          Jesse Glick added a comment -

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

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

          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?

          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?

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

              Created:
              Updated:
              Resolved: