New pending builds should cancel previous pending builds of the same pull request

[vorburger]

This is most likely a new feature request, not a bug report (I had assumed ghprb does this.. my bad) :

New pending builds should cancel previous pending builds of the same pull request. The same said differently: Today (using 1.15-0 on Jenkins ver. 1.577 here), if someone pushes a new commit on a pull request branch which is already queued / pending to be built, you get 2 pending builds - however I'd assume most people would agree you only really care about the second anyway, and still building the first is a waste of time. If it helps it helps to clarify, here's how my Build Queue looks like right now - the point of this issue is that I'd love the #42 to magically have vanished when the #43 got into the Build Queue:

#43 (pending—Build #32 is already in progress (ETA:N/A)) sha1=origin/pr/14/merge ghprbActualCommit=72ed3d34c8b4ac1aecb2a67dfc9769a6dfba9a30 ghprbActualCommitAuthor=... ghprbActualCommitAuthorEmail=... ghprbTriggerAuthor= ghprbTriggerAuthorEmail= ghprbPullId=14 ghprbTargetBranch=master ghprbSourceBranch=ds-7813 ghprbPullAuthorEmail= ghprbPullDescription=GitHub pull request #14 of commit 72ed3d34c8b4ac1aecb2a67dfc9769a6dfba9a30 automatically merged. ghprbPullTitle=... ghprbPullLink=https://github.com/TemenosDS/DS/pull/14

#42 (pending—Build #32 is already in progress (ETA:N/A)) sha1=origin/pr/14/merge ghprbActualCommit=b58e1e78e353044fbef8f0671e63cc6ed7af500d ghprbActualCommitAuthor=... ghprbActualCommitAuthorEmail=... ghprbTriggerAuthor= ghprbTriggerAuthorEmail= ghprbPullId=14 ghprbTargetBranch=master ghprbSourceBranch=ds-7813 ghprbPullAuthorEmail= ghprbPullDescription=GitHub pull request #14 of commit b58e1e78e353044fbef8f0671e63cc6ed7af500d automatically merged. ghprbPullTitle=... ghprbPullLink=https://github.com/TemenosDS/DS/pull/14

[bantu]

A solution to this problem would probably fix (but at least mitigate) the problem described in #148, namely rewrite of history resulting in the earlier build to fail.

Also, it seems like jenkinsci#18 implements this.

[bantu]

An alternative (and possibly better) implementation could be: Instead of canceling the first build and requeing, the first build builds the updated pull request and no second build is added to the queue. This way, the PR is allowed to keep its position in the queue.

[bantu]

This seems to duplicate #151.

[DavidTanner]

I will do some digging to see if we can stop the build when it starts.

[DavidTanner]

Implemented in latest.

[karlhorky]

Awesome @DavidTanner, which version should we upgrade to? Do you have a reference to the commit(s) that implemented this? In master on GitHub it looks like the last commits were in February.

[madhavc]

@DavidTanner How do we make this property enabled? It still queuing up in the build jobs for every new commit. Is it default?

[robvelor]

@madhavc Did you figure this out?

[madhavc]

Yes..

[madhavc]

@robvelor ^^

[ranvijayj]

Hi, Just wanted to touch base upon this. I am using the above option.
In my PR builder, I trigger the job based on a new Pull Request and then once the job is triggered I execute shell on a remote server where the PR code is pulled and Python tests are run...

Just wanted to know that choosing that option just removes pending, queued PR jobs for the same PR right?
It doesn't cancel an already running PR job for the same PR, I mean a job that is in progress! Right?

So, a new PR builder job due to a new commit on the PR won't abort this ^^ current running job?
It will cancel any other pending PR builder jobs for which the execution has not started. RIght?

@madhavc @DavidTanner

Thanks!!