• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • workflow-job-plugin
    • None
    • 2.42

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


      Manual equivalent courtesy of bsquizz:

      def buildNumber = BUILD_NUMBER as int; if (buildNumber > 1) milestone(buildNumber - 1); milestone(buildNumber)
      

          [JENKINS-43353] Ability to abort all previous running builds

          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.

          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.

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

          Kamil Magomedov added a comment - bsquizz 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.

          kmagomedov

          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. 

          Brandon Squizzato added a comment - kmagomedov 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. 

          Kamil Magomedov added a comment - - edited

          bsquizz 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!

          Kamil Magomedov added a comment - - edited bsquizz 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!

          Paul Eipper added a comment -

          How to use the milestone solution in a declarative pipeline ? bsquizz Do you have a sample Jenkinsfile doing this?

          Paul Eipper added a comment - How to use the milestone solution in a declarative pipeline ? bsquizz Do you have a sample Jenkinsfile doing this?

          Stanislav Ovchar added a comment - Created PR  https://github.com/jenkinsci/pipeline-milestone-step-plugin/pull/18

          Donald Morton added a comment - - edited

          This code caused 100% CPU on my Jenkins server:

          def buildNumber = env.BUILD_NUMBER as int
          if (buildNumber > 1) milestone(buildNumber - 1)
          milestone(buildNumber)
          

          I had restarted Jenkins after a security patch, and 20-30 builds kicked off from Branch Indexing. They all hung on the milestone() step. I finally started trying to kill them all, but then I noticed CPU was maxed out at 100% and it was taking forever. Had to comment out the above code and restart to fix it. 

          Attached a thread dump.

          Donald Morton added a comment - - edited This code caused 100% CPU on my Jenkins server: def buildNumber = env.BUILD_NUMBER as int if (buildNumber > 1) milestone(buildNumber - 1) milestone(buildNumber) I had restarted Jenkins after a security patch, and 20-30 builds kicked off from Branch Indexing. They all hung on the milestone() step. I finally started trying to kill them all, but then I noticed CPU was maxed out at 100% and it was taking forever. Had to comment out the above code and restart to fix it.  Attached a thread dump.

          Kyle McKnight added a comment -

          Would also like to know how to do this in declarative pipeline 

          Kyle McKnight added a comment - Would also like to know how to do this in declarative pipeline 

          Kyle McKnight added a comment -

          I haven't tried it yet, but lkraider, found this stackoverflow comment https://stackoverflow.com/a/52811034/1272355 for doing this with declarative pipeline

          Kyle McKnight added a comment - I haven't tried it yet, but lkraider , found this stackoverflow comment https://stackoverflow.com/a/52811034/1272355  for doing this with declarative pipeline

          Kalle Niemitalo added a comment - - edited

          workflow-job-plugin #200 added support for:

          • properties([disableConcurrentBuilds(abortPrevious: true)]) as a step in a scripted pipeline
          • options { disableConcurrentBuilds abortPrevious: true } as a directive in a declarative pipeline

          I have a multibranch declarative pipeline in which I want to abort previous builds of pull requests but allow concurrent builds of branches. This cannot be done with the options directive because, although the value of the abortPrevious parameter can be made conditional, the disableConcurrentBuilds option itself cannot. I tried using the properties step instead but got a message saying it is not allowed:

          org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 52: Invalid step "properties" used - not allowed in this context - The properties step cannot be used in Declarative Pipelines @ line 52, column 17.
          

          I then moved that into a script step, and that seems to be working fine, but I don't understand why it is even disallowed in the first place.

          The options { when { … } } construct that was suggested in JENKINS-41392 comment 344397 would make things easier.

          Kalle Niemitalo added a comment - - edited workflow-job-plugin #200 added support for: properties( [disableConcurrentBuilds(abortPrevious: true)] ) as a step in a scripted pipeline options { disableConcurrentBuilds abortPrevious: true } as a directive in a declarative pipeline I have a multibranch declarative pipeline in which I want to abort previous builds of pull requests but allow concurrent builds of branches. This cannot be done with the options directive because, although the value of the abortPrevious parameter can be made conditional, the disableConcurrentBuilds option itself cannot. I tried using the properties step instead but got a message saying it is not allowed: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 52: Invalid step "properties" used - not allowed in this context - The properties step cannot be used in Declarative Pipelines @ line 52, column 17. I then moved that into a script step, and that seems to be working fine, but I don't understand why it is even disallowed in the first place. The options { when { … } } construct that was suggested in JENKINS-41392 comment 344397 would make things easier.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            31 Vote for this issue
            Watchers:
            42 Start watching this issue

              Created:
              Updated:
              Resolved: