Skip to content

Cannot automatically cancel existing running jobs on merge request updates.Β #1140

@breisig

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugFor changelog: Minor bug. Will be listed after featuresfeature request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions