-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build triggered needlessly after MR states change #633
Comments
Do you have To accomplish what you expect, you should just have |
Nope, |
How many webhooks do you have in the repository? In the job that this webhook triggers, is the Push Events unchecked as well? |
The project has 4 web hooks configured, each talking to a different Jenkins job (all Freestyle jobs). Let me know if you need more information |
Ok then that is weird, we basically have the same configuration. I'm using gitlab 9.4.3-ce. |
But the CE version does not have the "Approvers" functionality, right? The question is now: Is it a Gitlab issue (Maybe even fixed in a newer version), or is it a feature? |
What's the size of build history of this Jenkins job? |
The job retains 30 days of build records |
Hi guys, It seems that we have exactly the same issue as @1100101 mentioned. The issue itself is that when approver hits It's unexpected behavior because there no code changes is made since previous build that was triggered when merge request is opened or updated (by pushing new changes). It also seems to be a relatively new behavior because the same job setup was working correctly a while ago. I'm not a Java developer, but from what I see in code, there are only two possible cases for What do you think, could such issue be caused by some changes in Gitlab webhooks API or some regression in Gitlab plugin? Thanks in advance! Context Gitlab plugin version: 1.4.8 Gitlab web hooks Gitlab plugin settings
Rebuild open Merge Requests - |
Hi all, We are having a similar issue. We are using GitLab Plugin version With |
I think I have an idea why this might be happening to me: So my though is this: In Am I correct in this? |
Can anyone provide some feedback on this? |
Yes @1100101, I am observing the same behavior with GitLab 10.1.4-ee. Approvals are causing Merge Request events, which are causing my Jenkins job to run. In my case, the repository/commit triggering the event is different than the repository/commit being cloned by the Jenkins job. I do not want approvals to cause my job to run. I have a Jenkins Pipeline job that gets triggered by GitLab's Jenkins CI integration. The pipeline is defined in pipeline.git, which Jenkins clones automatically. When a Merge Request event happens in projectA.git, the Jenkins job reads environment variables to determine which repository/commit caused the Merge Request event. Then it clones that repository at the specified commit and executes tests against it. The job clones other repositories as well. I did not notice any environment variables that I can use to abort the job early if it's running due to an approval. |
Sounds like a bug. Sorry for the delay in looking at this. @1100101 can you please capture logs from the plugin when a build is triggered from an MR approval? Look at the User Support section of the README if you need guidance on that. I will look into filtering these. |
Hi @omehegan, here's hopefully the relevant log entry.
Two notable items in the JSON are:
|
@1100101 yes I see now, it's the |
Also need to check other possible 'action' values, to filter label changes, edits, reassignments etc. |
That’s true. Editing the description of a MR actually also triggers a new build. |
@1100101 I can't find a doc that explains the possible values of the 'action' field. I also tried grepping through the code but didn't come up with anything. @dblessing can you point me toward anything for this? |
GitLab Enterprise Edition 10.1.1-ee Add label, edit description, and resolve todo produce exactly the same webhook requests (except of correspondingly changed description and values that represent current time). There is a field Log
{
"object_kind": "merge_request",
"user": {
"name": "Pavel Birukov",
"username": "pbirukov",
"avatar_url": "***FILTERED***"
},
"project": {
"name": "***FILTERED***",
"description": "***FILTERED***",
"web_url": "***FILTERED***",
"avatar_url": "***FILTERED***",
"git_ssh_url": "***FILTERED***",
"git_http_url": "***FILTERED***",
"namespace": "***FILTERED***",
"visibility_level": 10,
"path_with_namespace": "***FILTERED***",
"default_branch": "develop",
"ci_config_path": null,
"homepage": "***FILTERED***",
"url": "***FILTERED***",
"ssh_url": "***FILTERED***",
"http_url": "***FILTERED***"
},
"object_attributes": {
"id": 19311,
"target_branch": "develop",
"source_branch": "***FILTERED***",
"source_project_id": 152,
"author_id": 31,
"assignee_id": 31,
"title": "***FILTERED***",
"created_at": "2018-01-11 16:03:13 UTC",
"updated_at": "2018-01-19 08:39:33 UTC",
"milestone_id": null,
"state": "opened",
"merge_status": "cannot_be_merged",
"target_project_id": 152,
"iid": 10435,
"description": "",
"updated_by_id": 31,
"merge_error": null,
"merge_params": {
"force_remove_source_branch": "1"
},
"merge_when_pipeline_succeeds": false,
"merge_user_id": null,
"merge_commit_sha": null,
"deleted_at": null,
"in_progress_merge_commit_sha": null,
"lock_version": null,
"time_estimate": 0,
"last_edited_at": null,
"last_edited_by_id": null,
"head_pipeline_id": 65167,
"ref_fetched": true,
"merge_jid": null,
"discussion_locked": null,
"approvals_before_merge": null,
"rebase_commit_sha": null,
"squash": false,
"source": {
"name": "***FILTERED***",
"description": "***FILTERED***",
"web_url": "***FILTERED***",
"avatar_url": "***FILTERED***",
"git_ssh_url": "***FILTERED***",
"git_http_url": "***FILTERED***",
"namespace": "***FILTERED***",
"visibility_level": 10,
"path_with_namespace": "***FILTERED***",
"default_branch": "develop",
"ci_config_path": null,
"homepage": "***FILTERED***",
"url": "***FILTERED***",
"ssh_url": "***FILTERED***",
"http_url": "***FILTERED***"
},
"target": {
"name": "***FILTERED***",
"description": "***FILTERED***",
"web_url": "***FILTERED***",
"avatar_url": "***FILTERED***",
"git_ssh_url": "***FILTERED***",
"git_http_url": "***FILTERED***",
"namespace": "***FILTERED***",
"visibility_level": 10,
"path_with_namespace": "***FILTERED***",
"default_branch": "develop",
"ci_config_path": null,
"homepage": "***FILTERED***",
"url": "***FILTERED***",
"ssh_url": "***FILTERED***",
"http_url": "***FILTERED***"
},
"last_commit": {
"id": "dc9d099b24e2211a31f4bec5a79485491ffdc5e4",
"message": "***FILTERED***",
"timestamp": "2018-01-11T18:01:42+02:00",
"url": "***FILTERED***",
"author": {
"name": "Pavel Birukov",
"email": "***FILTERED***"
}
},
"work_in_progress": false,
"total_time_spent": 0,
"human_total_time_spent": null,
"human_time_estimate": null,
"url": "***FILTERED***",
"action": "update"
},
"labels": [
{
"id": 166,
"title": "Package",
"color": "#CCC",
"project_id": 152,
"created_at": "2017-07-26 15:33:14 UTC",
"updated_at": "2017-07-26 15:33:14 UTC",
"template": false,
"description": "",
"type": "ProjectLabel",
"group_id": null
}
],
"repository": {
"name": "***FILTERED***",
"url": "***FILTERED***",
"description": "***FILTERED***",
"homepage": "***FILTERED***"
},
"assignee": {
"name": "Pavel Birukov",
"username": "pbirukov",
"avatar_url": "***FILTERED***"
}
} |
@R00GER thanks, this is helpful. Looks like there are at least two possible values for 'action:' 'update' and 'approved.' I wonder if there is another value for pushes to the MR. I would think that most people would want to build on MR open, pushes to MR, and maybe approvals. Need some input from @dblessing or someone else at GitLab, unless I can make some time to test other cases. |
I've examind the log files from Jenkins to find out which states Log after updating MR description/settings
Log after pushing new commit
In the latter case, an additional JSON value |
It seems issue #659 is the opposite of my issue, but regarding the I'm currently not able to verify this by installing the latest plugin version, unfortunately :/ |
@omehegan I was able to reproduce an issue with Gitlab 10.4.3-ee and and the plugin build from a2b8394 A build is triggered when a MR is approved even though the build is configured with I will try to find the root cause, there are however two strange things. First: I was not able to reproduce the above issue previously so there might be some incompatible hook changes between Gitlab versions. Second: this issue was reported before any of my PRs were even opened (not to mention merged). There has to be some other factor at work here. Maybe it would also explain why I was unable to reproduce the issue before. |
This was fixed/released in version 1.5.4 of the plugin, which should be available in the update center soon. |
This bug appears to be back. Using GitLab Plugin 1.5.11. Same configuration as discussed: Push Events no checked, "Merge request events" checked. |
as I can see, Gitlab is sending |
I have several Jenkins jobs with parallel executing on Push Events, Tag Push Events and MR Events. Gitlab-plugin settings are "Open MR" and "Rebuild on push to source branch". |
Same issue happens again, with the latest version. |
I have the same issue:
See also my comment on #796 |
Issue
Our gitlab is set up so that each merge request must be approved by 1 or 2 reviewers before it can be merged. In addition Jenkins has to successfully build the project with the proposed changes.
When a reviewer hits the "Approve" button, the "Merge Request" webhook is triggerd, causing Jenkins to build the project again, even if it was successfully built previously.
Context
Logs & Traces
Problem description
Gitlab sends a "Merge Request" json with action "approved".
That action is apparently not evaluated, and it is also not checked whether there were actual changes committed to the feature branch.
Expected:
Hitting "Approve" in Gitlab does not trigger a new build in Jenkins.
The text was updated successfully, but these errors were encountered: