Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Duplicate
Description
This ticket is to request functionality to abort ongoing builds of PR if new change to the same PR was submitted, similarly like is done in the gerrit-trigger-plugin (see: https://github.com/jenkinsci/gerrit-trigger-plugin/pull/326).
I couldn't find a way to configure this with the current latest version (2.2.3) of the Bitbucket Branch Source Plugin, but I believe that this function is quite key as it is kind of pointless to keep testing an outdated PR once the code in it was changed, so there should be an option to, in the case of a PR code update (changed or new commits), current and queued job(s) for that PR should be aborted and only the job testing the last changes should run.
Attachments
Issue Links
- is related to
-
-
- Resolved
-
-
JENKINS-32997 Pipeline job: Abort older builds which are running
-
- Resolved
-
-
JENKINS-38409 Cancel ongoing testing of current PR if the PR gets updated with new/changed commits
-
- Resolved
-
-
-
- Resolved
-
Activity
First of all I think it should be an option of the plugin to handle this scenario, preferable optionally. Next I made an attempt to your suggestion pixman20, but that seems to not work if I do the following:
- PR build 1 is started, so passing milestone(1)
- PR build 2 is started, also passing milestone(1)
Still both PR build 1 and PR build 2 will continue, and that seems to be also in the light of what is stated in the wiki page:
> The milestone step ensures an older build will not override a newer build, so the older build will never be allowed to pass a milestone (it is aborted) if a newer build already passed it.
In the scenario I have drafted both builds actually already passed the defined milestone(). I am really interested in stopping PR build 1 as soon as PR build 2 is started as the first one is in context of PR no longer relevant.
Maikel vd Hurk
added a comment - - edited First of all I think it should be an option of the plugin to handle this scenario, preferable optionally. Next I made an attempt to your suggestion pixman20 , but that seems to not work if I do the following:
PR build 1 is started, so passing milestone(1)
PR build 2 is started, also passing milestone(1)
Still both PR build 1 and PR build 2 will continue, and that seems to be also in the light of what is stated in the wiki page:
> The milestone step ensures an older build will not override a newer build, so the older build will never be allowed to pass a milestone (it is aborted) if a newer build already passed it.
In the scenario I have drafted both builds actually already passed the defined milestone(). I am really interested in stopping PR build 1 as soon as PR build 2 is started as the first one is in context of PR no longer relevant. This looks like it might be a work around: https://stackoverflow.com/a/48956042
But I agree there should be a builtin pipeline option for this.
Related context: The GitHub build plugin provides a feature for this:https://github.com/jenkinsci/ghprb-plugin/issues/411
A similar question was asked here: https://issues.jenkins-ci.org/browse/JENKINS-32997
nickbrown
Cool, so the behavior just needs porting to bitbucket plugin. Do you have time to submit a PR?
bitwiseman just porting assumes the code that implements the behavior is the same for each plugin. They may work in different ways.
Beyond that, I'm also not familiar with the code or implementation design/behaviors of either plugin.
Could you just put a milestone at the beginning of the build if it's a PR build?
https://wiki.jenkins.io/display/JENKINS/Pipeline+Milestone+Step+Plugin
That should abort the previous PR build when the next one starts up.
Note that you'll have to allow concurrent builds.