Pushing the code and triggering new job will not abort the previous one, making the user wait for the results of the previous job before the new one is performed. It would be nice if there was an option to abort the existing job and immediately start running the new one.

       

      Here's the similar issue reported against github-organization-folder-plugin: https://issues.jenkins-ci.org/browse/JENKINS-38409

       

      Here's the issue in the old Github Pull request builder plugin where it was implemented: https://github.com/jenkinsci/ghprb-plugin/issues/241

          [JENKINS-43132] Cancel existing job if the new job is pending

          Brian Saville added a comment -

          You can use the milestone step to accomplish this - this is what we're doing for PR builds.

          Brian Saville added a comment - You can use the milestone step to accomplish this - this is what we're doing for PR builds.

          You can use workaround:

          killall_jobs()

          @NonCPS
          def killall_jobs() {
          def jobname = env.JOB_NAME
          def buildnum = env.BUILD_NUMBER.toInteger()

          def job = Jenkins.instance.getItemByFullName(jobname)
          for (build in job.builds) {
          if (!build.isBuilding())

          { continue; }

          if (buildnum == build.getNumber().toInteger())

          { continue; println "equals" }

          echo "Kill task = ${build}"
          build.doStop();
          }
          }

          Viacheslav Dubrovskyi added a comment - You can use workaround: killall_jobs() @NonCPS def killall_jobs() { def jobname = env.JOB_NAME def buildnum = env.BUILD_NUMBER.toInteger() def job = Jenkins.instance.getItemByFullName(jobname) for (build in job.builds) { if (!build.isBuilding()) { continue; } if (buildnum == build.getNumber().toInteger()) { continue; println "equals" } echo "Kill task = ${build}" build.doStop(); } }

          I was trying to use this workaround, but it doesn't seem to be suitable for my use case, as I use declarative pipeline and a "dockerfile agent". So I think the whole docker image will be built (which is one of the most time consuming parts of the job) before the killall_jobs() function can be used.

          Leandro Lucarella added a comment - I was trying to use this workaround, but it doesn't seem to be suitable for my use case, as I use declarative pipeline and a "dockerfile agent". So I think the whole docker image will be built (which is one of the most time consuming parts of the job) before the killall_jobs() function can be used.

          I raised the priority to Major (I wish there was a severity field, as I can't handle the priorities really), but for us, having dozens of projects that build several PRs concurrently, not having a way to abort useless builds is making the jenkins server stop being practical.

          Leandro Lucarella added a comment - I raised the priority to Major (I wish there was a severity field, as I can't handle the priorities really), but for us, having dozens of projects that build several PRs concurrently, not having a way to abort useless builds is making the jenkins server stop being practical.

          Jesse Glick added a comment -

          Duplicate of JENKINS-43353.

          Jesse Glick added a comment - Duplicate of JENKINS-43353 .

            Unassigned Unassigned
            nemanjaboric Nemanja Boric
            Votes:
            12 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: