Current behavior
LPRB fires off new builds when the PR is updated. Generally, the only builds that matter are the latest builds that match the current head of the PR. However, the existing/pending builds are left to start/finish as they are processed by Jenkins.
Problem
Some build infrastructure is under provisioned for the amount of work delegated. Eliminating unnecessary work with this feature would be an "easy" (read: cheaper than paying for more infrastructure and/or wasting resources) way to reduce time it takes for a given PR to receive a relevant completed check.
Proposal
Jenkins has api to retrieve the queued build list: /queue/api/json?pretty=true
And, api to retrieve information about a queued item (1234 being the item id): /queue/item/1234/api/json?pretty=true
The queued item data includes parameters the triggered the job, and we can pass additional parameters that aren't necessarily used by the job, like the PR id. https://github.com/bgrainger/leeroy-pull-request-builder/blob/4d5afd152bda2df57beb650121787c2672f6c6b3/src/server.js#L285
Additionally, there is api to cancel queued builds: /queue/cancelItem?id=1234
I think that we can include the unique pr id we have when triggering a build, and then, before triggering a new build, simply cancel any pending jobs matching this pr id.
At the same time, we might also cancel in-progress jobs, but will need to track/query them using different apis methods.
Current behavior LPRB fires off new builds when the PR is updated. Generally, the only builds that matter are the latest builds that match the current head of the PR. However, the existing/pending builds are left to start/finish as they are processed by Jenkins.
Problem Some build infrastructure is under provisioned for the amount of work delegated. Eliminating unnecessary work with this feature would be an "easy" (read: cheaper than paying for more infrastructure and/or wasting resources) way to reduce time it takes for a given PR to receive a relevant completed check.
Proposal Jenkins has api to retrieve the queued build list:
/queue/api/json?pretty=true
And, api to retrieve information about a queued item (1234 being the item id):/queue/item/1234/api/json?pretty=true
The queued item data includes parameters the triggered the job, and we can pass additional parameters that aren't necessarily used by the job, like the PR id. https://github.com/bgrainger/leeroy-pull-request-builder/blob/4d5afd152bda2df57beb650121787c2672f6c6b3/src/server.js#L285 Additionally, there is api to cancel queued builds:/queue/cancelItem?id=1234
I think that we can include the unique pr id we have when triggering a build, and then, before triggering a new build, simply cancel any pending jobs matching this pr id.
At the same time, we might also cancel in-progress jobs, but will need to track/query them using different apis methods.