• 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

          Jesse Glick created issue -

          Jesse Glick added a comment -

          Might be considered a duplicate of JENKINS-40936, though the use cases are a little different: this RFE applies even to jobs with no manual approval step, and no need for interior milestones of any kind.

          Jesse Glick added a comment - Might be considered a duplicate of  JENKINS-40936 , though the use cases are a little different: this RFE applies even to jobs with no manual approval step, and no need for interior milestones of any kind.
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-40936 [ JENKINS-40936 ]

          Jesse Glick added a comment -

          While something like an eager flag would be perfect, I am filing a PR showing a workaround: start your Jenkinsfile with

          for (int i = 0; i < (BUILD_NUMBER as int); i++) {milestone()}
          

          Jesse Glick added a comment - While something like an eager flag would be perfect, I am filing a PR showing a workaround: start your Jenkinsfile with for ( int i = 0; i < (BUILD_NUMBER as int ); i++) {milestone()}
          Jesse Glick made changes -
          Remote Link New: This issue links to "PR 12 (Web Link)" [ 15849 ]

          This is another option:

          @NonCPS
          void cancelPreviousRunningBuilds(int maxBuildsToSearch = 20) {
              RunWrapper b = currentBuild
              for (int i=0; i<maxBuildsToSearch; i++) {
                  b = b.getPreviousBuild();
                  if (b == null) break;
                  Run<?,?> rawBuild = b.rawBuild
                  if (rawBuild.isBuilding()) {
                      rawBuild.doStop()
                  }
              }
          }
          

          Just call cancelPreviousRunningBuilds() at the very fist line of the pipeline.

          Antonio Muñiz added a comment - This is another option: @NonCPS void cancelPreviousRunningBuilds( int maxBuildsToSearch = 20) { RunWrapper b = currentBuild for ( int i=0; i<maxBuildsToSearch; i++) { b = b.getPreviousBuild(); if (b == null ) break ; Run<?,?> rawBuild = b.rawBuild if (rawBuild.isBuilding()) { rawBuild.doStop() } } } Just call cancelPreviousRunningBuilds() at the very fist line of the pipeline.

          Sam Van Oort added a comment -

          jglick This is confusingly worded – could it be rephrased as "abort previous running builds even after they've passed the milestone"?

          Sam Van Oort added a comment - jglick This is confusingly worded – could it be rephrased as "abort previous running builds even after they've passed the milestone"?

          Jesse Glick added a comment -

          Not necessarily. The milestone step is simply a tool which could be used to implement this. The use case is to abort all previous running builds. See my first comment.

          Jesse Glick added a comment - Not necessarily. The milestone step is simply a tool which could be used to implement this. The use case is to abort all previous running builds. See my first comment.
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-39180 [ JENKINS-39180 ]

          When pushing new changes to a PR, it would be awesome if the multi branch had an option to automatically kill all previous running builds/queued builds for that branch so that only the latest gets queued/built. This way if a developer commits and pushes and then does the same again immediately afterwards we don't have two builds, especially if the builds take 20+ minutes each, and we don't care about the intermediate result.

          Bert JW Regeer added a comment - When pushing new changes to a PR, it would be awesome if the multi branch had an option to automatically kill all previous running builds/queued builds for that branch so that only the latest gets queued/built. This way if a developer commits and pushes and then does the same again immediately afterwards we don't have two builds, especially if the builds take 20+ minutes each, and we don't care about the intermediate result.

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

              Created:
              Updated:
              Resolved: