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

Add option to automatically abort old builds on new commits in GitHub pull request

      The problem when GitHub organization is configured:

      Every day there are several active pull requests, that are being modified after new comments from reviewers.

      At the same time Jenkins is building these pull requests and branches. All the executors are busy and there is a queue of waiting builds.

      Pretty often, after new commits, new build is started in a pull request, while previous build is still running. New build has to wait for the unfinished build to complete before it can start. This makes developers wait more and wastes jenkins recourses.

      New build in pull request should abort unneeded previous builds in progress. This should happen when new build goes to the queue, long before it reaches next available executor.

      This behavior should not apply to branch builds. This would make a long series of aborted builds on master during hot development days.

          [JENKINS-48906] Add option to automatically abort old builds on new commits in GitHub pull request

          AnneTheAgile added a comment - - edited

          I agree this is an issue, but I am not sure of the right programmatic way to fix / workaround. Jenkins leader does run some little part of the job to start; ideas so far;

          1.maybe one way would be to divide each job into two parts. Part1 checks to ensure no existing job for this pull. I think that should be straightforward by checking  [finish time? start time?] of [last job if any]. If it finds one, it would need to abort it, which in GUI requires an ack. I'm not sure if there is an API to abort. Then Part2 would do the normal job.

          2.at top of job,  [if parallel jobs are enabled] put in a delay eg 30 seconds and look for a new commit, if finding one more recent than 'me', then I defer to it by quick failing/passing/intermediate.

          3.if jobs have steps that are separable, between each step  [2] could be done. I might try to do that.

          AnneTheAgile added a comment - - edited I agree this is an issue, but I am not sure of the right programmatic way to fix / workaround. Jenkins leader does run some little part of the job to start; ideas so far; 1.maybe one way would be to divide each job into two parts. Part1 checks to ensure no existing job for this pull. I think that should be straightforward by checking  [finish time? start time?] of [last job if any] . If it finds one, it would need to abort it, which in GUI requires an ack. I'm not sure if there is an API to abort. Then Part2 would do the normal job. 2.at top of job,  [if parallel jobs are enabled] put in a delay eg 30 seconds and look for a new commit, if finding one more recent than 'me', then I defer to it by quick failing/passing/intermediate. 3.if jobs have steps that are separable, between each step  [2] could be done. I might try to do that.

          Thank for the ideas. These help in some cases, but still for steps that cannot be split this issue needs to be implemented.

          Not sure about internal implementation, but logically long steps could be added with a flag, that tells Jenkins to abort when new build appears.

          Alexander Vorobiev added a comment - Thank for the ideas. These help in some cases, but still for steps that cannot be split this issue needs to be implemented. Not sure about internal implementation, but logically long steps could be added with a flag, that tells Jenkins to abort when new build appears.

          AnneTheAgile added a comment - - edited

          vorobievalex Well,  Jenkins as a whole already has an 'abort' that works ok , right? Long running steps are definitely cancelled, and the log is even updated correctly in all but a very few cases, eg before the job really starts.  I was even able to find a related code section PR; https://github.com/jenkinsci/jenkins/pull/1835

          AnneTheAgile added a comment - - edited vorobievalex Well,  Jenkins as a whole already has an 'abort' that works ok , right? Long running steps are definitely cancelled, and the log is even updated correctly in all but a very few cases, eg before the job really starts.  I was even able to find a related code section PR; https://github.com/jenkinsci/jenkins/pull/1835

          Yes, there is an X button with confirmation for manual aborts. There is also a timeout threshold.

          This request is to make Jenkins automatically abort a build (without a confirmation) when new commits arrive at the same branch.

          Imagin a situation: developer submits a Pull Request. This initiates tests to be started. Let us say tests take 1 hour. 10 minutes later developer adds a minor commit to the same PR. PR approval will be ready after 1 hour 50 minutes only. The developer can go to Jenkins and abort the 1st build manually, but this is such a common use case, so should be automated.

          Alexander Vorobiev added a comment - Yes, there is an X button with confirmation for manual aborts. There is also a timeout threshold. This request is to make Jenkins automatically abort a build (without a confirmation) when new commits arrive at the same branch. Imagin a situation: developer submits a Pull Request. This initiates tests to be started. Let us say tests take 1 hour. 10 minutes later developer adds a minor commit to the same PR. PR approval will be ready after 1 hour 50 minutes only. The developer can go to Jenkins and abort the 1st build manually, but this is such a common use case, so should be automated.

            Unassigned Unassigned
            vorobievalex Alexander Vorobiev
            Votes:
            7 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: