Gitlab-plugin: Labeling an open MR triggers a build

Created on 17 Dec 2018 · 20Comments · Source: jenkinsci/gitlab-plugin

Issue

When making minor changes to an open merge request that should not affect the result of the Jenkins run, a rebuild is triggered still.
This includes adding/removing a label, setting/removing a milestone, as well as editing the description (or title) of the MR.

Note: This issue is closely related to issue #696, which was closed as a duplicate to #633, which did not fix the issues described here (or in #696).

Context

Gitlab plugin version: 1.5.5
Gitlab version: 10.4.6 EE
Jenkins version: 2.138.2
Job type: Freestyle

Logs & Traces

Here's a log extract from Jenkins.
The relevant part is the changes section. In this case, I only changed the Milestone assignment for the MR:

WebHook called with url: /project/navi-builder

Dec 17, 2018 8:37:36 AM FINE com.dabsquared.gitlabjenkins.webhook.build.MergeRequestBuildAction

MergeRequest: {
  "object_kind" : "merge_request",
  "user" : {
    "name" : "Frank Aurich",
    "username" : "f.aurich",
    "avatar_url" : ***FILTERED***
  },
  "project" : {
    "id" : 1242,
    "name" : ***FILTERED***,
    "description" : "",
    "web_url" : ***FILTERED***,
    "avatar_url" : null,
    "git_ssh_url" : ***FILTERED***,
    "git_http_url" : ***FILTERED***,
    "namespace" : ***FILTERED***,
    "visibility_level" : 10,
    "path_with_namespace" : ***FILTERED***,
    "default_branch" : "mw_develop",
    "ci_config_path" : null,
    "homepage" : ***FILTERED***,
    "url" : ***FILTERED***,
    "ssh_url" : ***FILTERED***,
    "http_url" : ***FILTERED***
  },
  "object_attributes" : {
    "assignee_id" : 316,
    "author_id" : 316,
    "created_at" : "2018-12-14 17:18:58 +0100",
    "description" : ***FILTERED***,
    "head_pipeline_id" : 61912,
    "id" : 26510,
    "iid" : 63,
    "last_edited_at" : "2018-12-14 17:19:30 +0100",
    "last_edited_by_id" : 316,
    "merge_commit_sha" : null,
    "merge_error" : null,
    "merge_params" : {
      "force_remove_source_branch" : "1"
    },
    "merge_status" : "can_be_merged",
    "merge_user_id" : null,
    "merge_when_pipeline_succeeds" : false,
    "milestone_id" : 4676,
    "source_branch" : "bugfix/DEFECT-34585",
    "source_project_id" : 1242,
    "state" : "opened",
    "target_branch" : "mw_develop",
    "target_project_id" : 1242,
    "time_estimate" : 0,
    "title" : ***FILTERED***,
    "updated_at" : "2018-12-17 08:37:35 +0100",
    "updated_by_id" : 83,
    "url" : ***FILTERED***,
    "source" : {
      "id" : 1242,
      "name" : ***FILTERED***,
      "description" : "",
      "web_url" : ***FILTERED***,
      "avatar_url" : null,
      "git_ssh_url" : ***FILTERED***,
      "git_http_url" : ***FILTERED***,
      "namespace" : ***FILTERED***,
      "visibility_level" : 10,
      "path_with_namespace" : ***FILTERED***,
      "default_branch" : "mw_develop",
      "ci_config_path" : null,
      "homepage" : ***FILTERED***,
      "url" : ***FILTERED***,
      "ssh_url" : ***FILTERED***,
      "http_url" : ***FILTERED***
    },
    "target" : {
      "id" : 1242,
      "name" : ***FILTERED***,
      "description" : "",
      "web_url" : ***FILTERED***,
      "avatar_url" : null,
      "git_ssh_url" : ***FILTERED***,
      "git_http_url" : ***FILTERED***,
      "namespace" : ***FILTERED***,
      "visibility_level" : 10,
      "path_with_namespace" : ***FILTERED***,
      "default_branch" : "mw_develop",
      "ci_config_path" : null,
      "homepage" : ***FILTERED***,
      "url" : ***FILTERED***,
      "ssh_url" : ***FILTERED***,
      "http_url" : ***FILTERED***
    },
    "last_commit" : {
      "id" : "1e2c74baffb976fe16e8cfe2490826609009a1a8",
      "message" : ***FILTERED***,
      "timestamp" : "2018-12-14T17:10:24+01:00",
      "url" : ***FILTERED***,
      "author" : {
        "name" : ***FILTERED***,
        "email" : ***FILTERED***
      }
    },
    "work_in_progress" : false,
    "total_time_spent" : 0,
    "human_total_time_spent" : null,
    "human_time_estimate" : null,
    "action" : "update"
  },
  "labels" : [ ],
  "changes" : {
    "milestone_id" : {
      "previous" : null,
      "current" : 4676
    },
    "updated_at" : {
      "previous" : "2018-12-17 08:35:19 +0100",
      "current" : "2018-12-17 08:37:35 +0100"
    },
    "updated_by_id" : {
      "previous" : 316,
      "current" : 83
    }
  },
  "repository" : {
    "name" : ***FILTERED***,
    "url" : ***FILTERED***,
    "description" : "",
    "homepage" : ***FILTERED***
  },
  "assignee" : {
    "name" : ***FILTERED***,
    "username" : ***FILTERED***,
    "avatar_url" : ***FILTERED***
  }
}

Dec 17, 2018 8:37:36 AM INFO com.dabsquared.gitlabjenkins.trigger.handler.AbstractWebHookTriggerHandler handle

navi-builder triggered for merge request.

Here is changes section after a new label has been added to an MR:

[...]
"changes" : {
    "labels" : {
      "previous" : [ ],
      "current" : [ {
        "id" : 3348,
        "title" : "X137",
        "color" : "#44AD8E",
        "project_id" : null,
        "created_at" : "2018-12-17 08:40:27 +0100",
        "updated_at" : "2018-12-17 08:40:27 +0100",
        "template" : false,
        "description" : "Relevant SW change for SW137",
        "type" : "GroupLabel",
        "group_id" : 43
      } ]
    }
  },
[...]

Problem description

In Gitlab, a webhook is configured to be triggered on Merge Request and Comment.
Expected:
Jenkins starts a new build job when new commits to the MR branch occur, or when someone triggers the Jenkins manually via a special comment in Gitlab.
Actual:
Jenkins triggers a job when changes are made to the MR that are not relevant to the Jenkins build:
label changes, milestone changes, changes to the description of the MR, changes to the number of approvers (Gitlab EE).

bug

Source

1100101

Most helpful comment

We have the same issue but I think this is because we have a merge before build strategy in our job.
An option to check the commit hash from the source branch instead of the merge commit would be fine.

nmenetrier on 21 Jun 2019

👍2

All 20 comments

@r00ger are you still having this issue as well?

omehegan on 18 Dec 2018

I have same problem.
Same commit may be build 2-4 times (parallel builds enable)
gitlab-plugin 1.5.11

trunov-ms on 21 Dec 2018

@omehegan not anymore

pablobirukov on 21 Dec 2018

I have a repo in Gitlab and several Jenkins jobs called by hooks on Push Events, Tag Push Events and MR Events. In Jenkins jobs gitlab-plugin settings of build cause are "Open MR" and "Rebuild on push to source branch".
Each job sets a label in MR depending on the build result.
After MR labels change, Gitlab call hooks again with MR change event.
Jobs which run builds in parallel and building executed at this time are triggerring again with same commit.

trunov-ms on 21 Dec 2018

Something that might be of help investigating this issue: the gitlab repository that triggers the job is actually not the one being built by Jenkins.
That means the commit hashes differ (always!).
As a result, the plugin's "I've built this revision before, let's skip it mechanism" won't be triggered.

Maybe that's why only some people are experiencing this issue.

1100101 on 14 Feb 2019

I am also seeing this issue when removing "WIP:" from an MR.
Gitlab plugin version: 1.5.11
Gitlab version: 11.4.0-ee
Jenkins version: 2.163
Job type: Matrix

In all the "re-fires," the git commit hash is the same as the job that succeeded, and thus prompted me to remove the "WIP:" label git checkout -f c13e82b2f7b6be55b2c14d0188624211f4911edc

jkugler on 14 Feb 2019

https://github.com/jenkinsci/gitlab-plugin/issues/633#issuecomment-463671503

as I can see, Gitlab is sending "event_type": "merge_request" when MR description changes..
Even though changes contains only description related updates, build is triggered..
imho, plugin should ignore non-code changes and not trigger a build, with exception of comment-based trigger phrase

anapsix on 15 Feb 2019

I agree with @anapsix comment. Should only trigger a build if changes contains code changes or comments with trigger-phrase.

Also, as mentioned in #900, I would also like to be able to specify specific labels that would trigger the build.

anton-johansson on 28 Feb 2019

Update: I experienced these issues too, but after checking the comment by @1100101:

Something that might be of help investigating this issue: the gitlab repository that triggers the job is actually not the one being built by Jenkins.

I had a test pipeline configured, and this was the cause. With a "real" set up, everything works as expected.

Also, see my PR about forcing builds with added labels: #903

anton-johansson on 6 Mar 2019

We also experience this issue, when only the mergerequest description changes or the mergerequest is labeled/assigned to a milestone a new build is triggered.
We only have the "Opened Merge Request Events" option ticked and "Rebuild open Merge Requests: On push to source branch". ( also "Approved Merge Requests (EE-only)" and "Comments" which should be irrelevant). Jenkins 2.150.3, gitlab plugin 1.5.11, gitlab 11.8.1 CE

fschloesser on 6 Mar 2019

@fschloesser: And you're actually building the same branch that triggers the build? By checking out that branch with the SCM/Git plugin?

anton-johansson on 6 Mar 2019

@anton-johansson yes, though we do the additional behaviour "merge before build"

fschloesser on 6 Mar 2019

@anton-johansson We are also building the branch that triggers the build.

jkugler on 6 Mar 2019

Another data point: new builds are getting triggered when the "assigned" is changed on an MR, or even the title of the MR is changed.

jkugler on 13 Mar 2019

Also seeing this when adding or modifying approvers on a PR (in additional to assigning or changing the title) in 1.5.11.

mslaven on 14 Mar 2019

I'm also seeing this issue:

In response to questions:

And you're actually building the same branch that triggers the build? By checking out that branch with the SCM/Git plugin?

Yes, branches to build is specified as origin/${gitlabSourceBranch}.

sandbox on 5 Apr 2019

nmenetrier on 21 Jun 2019

👍2

We have the same issue, and also our MRs are triggered on Assignee field changing, on Description or Summary fields changing.
We're using GitLab CE 11.3.1 and Pipeline jobs, trigger is set to Merge Request events.
Please let me know if you need additional information

ababushk on 11 Jul 2019

In ATLAS collaboration (CERN) we have similar issues. We need a job triggered when git push to source branch of opened MR occurs, or when MR is opened. Therefore in GitLab webhook options we set the Trigger on "Merge request event" and in Jenkins (v. 2.176.1) freestyle job for gitlab plugin (v. 1.5.12) we enabled triggers: "Opened Merge Request Events", "Rebuild open Merge Requests on push to source branch". When a job is triggered on push to source branch then there is a period of ~5 - 10 minutes - during the period when the plugin runs git commands - when any MR event (such as changing description, label) triggers a duplicate job. These duplicate jobs are triggered quite frequently because it is not a rare case when developers change description, labels, comments in few minutes after the push to repository and they create a lot of confusion, such as corrupted pipeline status in GitLab.

aundrus on 26 Jul 2019

These duplicate jobs are triggered quite frequently

You can avoid that by setting Jenkins job "Do not allow concurrent builds" and to reduce number of reruns "Cancel pending merge request builds on update".