-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
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.
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.