-
Improvement
-
Resolution: Unresolved
-
Major
-
None
When using a deployment strategy with an user input option older builds are cancelled as soon as the user acknowledges the input. That's working pretty well, however:
Frequent commits will clock up the executors all waiting on the same input if the user does not acknowledge 'quick' enough. We might be able to optimise this and free executors by automatically aborting old builds which are all sitting in the same milestone.
build #1
- milestone 1
- input
-milestone 2
build #2 (newer commit)
- milestone 1
- input
- milestone 2
When build #2 reaches the input it's effectively in milestone 1, where #1 is currently sitting as well. It could be very good if at this point we would be able to abort #1 as we have a new build in the same milestone.
I was not able to find a solution achieving above behaviour, but if that's otherwise possible, I would be very happy to implement it, although I believe it would be a good addition to excellent milestone pattern readily available.
- relates to
-
JENKINS-43353 Ability to abort all previous running builds
-
- Resolved
-
Depending on how many commits and runs are stacked up the lock step from the lockable resources plugin could help here:
In this case all of the builds will still stack up at the lock but they will get aborted much quicker. Assume you have 6 commits:
Build 1 will enter the lock and wait at the input. All other builds after that will wait at the lock.
When Build 1 passes the input the newest build waiting at the lock (say Build 5) enters the lock, passes the new milestone and waits at the input. As soon as Build 5 passes the new milestone all other builds (Builds 2,3,4) are aborted while Build 5 waits at the input
This doesn't eliminate the queue but it can dramatically reduce it if you have several builds waiting.