Cannot automatically cancel existing running jobs on merge request updates.

[breisig]

Having an issue [or a feature request] where when a user triggers an update to their code in their merge request that it doesn't automatically cancel the existing running job in Jenkins. So it just adds another request on top of the Jenkins queue and just keeps the existing job running which isn't very good especially if a job takes about 20 minutes to run.

Current Settings and Versions for Gitlab and Jenkins

Gitlab Web Hook Settings: Push events, Merge request events, Pipeline events, Deployments events
Jenkins Freestyle job Settings: Job has Enable Triggers [Pushed Events, Open Merge Requests Events, Accepted Merge Request Events, Approved Merge Requests], Enable Cancel pending merge requests builds on update. Post Build Action: Publish build status to Gitlab

Gitlab 13.12.2 [EE]
Jenkins 2.296
Jenkins Gitlab Plugin: 1.5.13 [1.5.20 breaks things]

So here's the situation, Developers open a merge requests [not in WIP mode] and are pushing new committed code to their branch. As normal, it would trigger off Jenkins job which does a bunch of checks to verify the code is good and once done, it returns a ok/failed status back to the merge request which is great. The Jenkins job however takes about 20+ minutes to run before it will send the status back to Gitlab.

The Issue(s) If a developer pushes something to their branch, Jenkins gets triggered to run the job.[which is fine] If they push another commit to their merge request branch within a few minutes, Their previous Jenkins job that was already running does not get killed and keeps running and a new job is queued has been added on top for it run. This causes the following issue.

1. To wait 20+ minutes AND then wait for queued job to run again is not very useful and time consuming especially for QA. We are ok if the job gets cancelled/killed midway.

2. This also causes an issue for bad code to be committed when a developer pushes to their merge request branch, QA clicks the 'To be merged automatically when the pipeline succeeds' button and then the developer realizes they forgot to commit something and committed + pushed it up while the previous Jenkins merge request job was running. What happens is the old jenkins job is still running in Jenkins and a new job is pushed on top of the Jenkins Queue to run so when the old merge request job finishes, it sends a success back to Gitlab which then automatically merges the bad code and now Jenkins runs that queue job runs but it's already too late as the bad code has already been merged.

Is their a way to get this fixed?

Expected result:

Jobs to get cancelled in Jenkins

Actual result:

Just gets queued.

[ghost]

Thanks for the idea i get this issue

[gavinc-git]

I have the same issue. This is noted in the wiki it is already available. Is there an ETA for fixing this?

https://github.com/jenkinsci/gitlab-plugin#cancel-pending-builds-on-merge-request-update

[breisig]

Yeah, that option doesn't kill the existing running jobs. :-(

[BreakBB]

A wild guess (after a quick look at the code) would be that cancelPendingBuilds in the PendingBuildsHandler.java can't find the job which has to be canceled.

[gavinc-git]

Is there anyupdate on the progress for this as yet?

[RemigiuszDudek]

That would be a very valuable feature, please let know if there is any progress.

[RemigiuszDudek]

I have posted a Pull Request (really small one), would appreciate if you could review (https://github.com/jenkinsci/gitlab-plugin/pull/1268)