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

Ability to abort all previous running builds

    Details

    • Similar Issues:

      Description

      It is sometimes desirable for a job (such as a branch project) to simply abort any previously running builds as soon as a new build starts. For example, in a branch project for a pull request, you might want to see test results from an earlier commit even after pushing follow-up commits, but most of the time you only care about the results of the PR head, and computer time might be too valuable to waste on the older ones.

      (I think gerrit-trigger does something like this automatically, and I have seen Alex Gray invent the same kind of pattern with JenkinsPy.)

      Merely setting the job to not be concurrent-capable does not suffice, since then newer builds will queue up waiting for the older ones to finish.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Yes, it should. When build 8 starts, it should abort builds 6 and 7. When a build is aborted, in turn, it should abort any sh steps already running inside any node blocks, and also cancel any queue items corresponding to node blocks which have not yet started.

            Show
            jglick Jesse Glick added a comment - Yes, it should. When build 8 starts, it should abort builds 6 and 7. When a build is aborted, in turn, it should abort any sh steps already running inside any node blocks, and also cancel any queue items corresponding to node blocks which have not yet started.
            Hide
            mark_han Mark Han added a comment -

            Ended up not using Milestone because it doesn't communicate the build # that was stopped. Instead we're trying to use 

            def cancelPreviousBuilds() {
             // Check for other instances of this particular build, cancel any that are older than the current one
             def jobName = env.JOB_NAME
             def currentBuildNumber = env.BUILD_NUMBER.toInteger()
             def currentJob = Jenkins.instance.getItemByFullName(jobName)
            
             // Loop through all instances of this particular job/branch
             for (def build : currentJob.builds) {
             if (build.isBuilding() && (build.number.toInteger() < currentBuildNumber)) {
             echo "Older build still queued. Sending kill signal to build number: ${build.number}"
             build.doStop()
             }
             }
            }

            If we put this outside of our node blocks, things are working well. We previously had this in a node{} which was horrible, and resolved the issue after you informing me of the heavyweight vs flyweight executors.

            Show
            mark_han Mark Han added a comment - Ended up not using Milestone because it doesn't communicate the build # that was stopped. Instead we're trying to use  def cancelPreviousBuilds() { // Check for other instances of this particular build, cancel any that are older than the current one def jobName = env.JOB_NAME def currentBuildNumber = env.BUILD_NUMBER.toInteger() def currentJob = Jenkins.instance.getItemByFullName(jobName) // Loop through all instances of this particular job/branch for (def build : currentJob.builds) { if (build.isBuilding() && (build.number.toInteger() < currentBuildNumber)) { echo "Older build still queued. Sending kill signal to build number: ${build.number}" build.doStop() } } } If we put this outside of our node blocks, things are working well. We previously had this in a node{} which was horrible, and resolved the issue after you informing me of the heavyweight vs flyweight executors.
            Hide
            kmagomedov Kamil Magomedov added a comment -

            Brandon Squizzato Not sure how your solution is supposed to work after the first build. Each subsequent build will create two milestones and pass them immediately. First build is the only one that will be aborted.

            Show
            kmagomedov Kamil Magomedov added a comment - Brandon Squizzato Not sure how your solution is supposed to work after the first build. Each subsequent build will create two milestones and pass them immediately. First build is the only one that will be aborted.
            Hide
            bsquizz Brandon Squizzato added a comment -

            Kamil Magomedov

            Build #1 would define milestone(1)
            Build #2 would define milestone(1) and milestone(2)
            Build #3 would define milestone(2) and milestone(3)
            Build #4 would define milestone(3) and milestone(4)

            and so on ...

            Every time a build runs, it is passing the highest milestone of the previous build. This causes the previous build to abort. From https://jenkins.io/doc/pipeline/steps/pipeline-milestone-step/

            > The milestone step forces all builds to go through in order, so an older build will never be allowed pass a milestone (it is aborted) if a newer build already passed it. 

            Show
            bsquizz Brandon Squizzato added a comment - Kamil Magomedov Build #1 would define milestone(1) Build #2 would define milestone(1) and milestone(2) Build #3 would define milestone(2) and milestone(3) Build #4 would define milestone(3) and milestone(4) and so on ... Every time a build runs, it is passing the highest milestone of the previous build. This causes the previous build to abort. From https://jenkins.io/doc/pipeline/steps/pipeline-milestone-step/ – > The milestone step forces all builds to go through in order, so an older build will never be allowed pass a milestone (it is aborted) if a newer build already passed it. 
            Hide
            kmagomedov Kamil Magomedov added a comment - - edited

            Brandon Squizzato ah, I apologize, I had the wrong idea about the way milestone works. I thought that for the older builds to be aborted the newest build has to pass at least one more milestone step. So three milestone steps for Build #3 and so on. That's how I always used it. Good to know that there's the other way, thank you!

            Show
            kmagomedov Kamil Magomedov added a comment - - edited Brandon Squizzato ah, I apologize, I had the wrong idea about the way milestone works. I thought that for the older builds to be aborted the newest build has to pass at least one more milestone step. So three milestone steps for Build #3 and so on. That's how I always used it. Good to know that there's the other way, thank you!

              People

              • Assignee:
                amuniz Antonio Muñiz
                Reporter:
                jglick Jesse Glick
              • Votes:
                10 Vote for this issue
                Watchers:
                18 Start watching this issue

                Dates

                • Created:
                  Updated: