Skip to content
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

Edit merge request description automatically triggers jenkins job if this job checkouts code from another repository #849

Closed
slxiao opened this issue Oct 26, 2018 · 2 comments

Comments

@slxiao
Copy link

slxiao commented Oct 26, 2018

Context

  • Gitlab plugin version: 1.5.10
  • Gitlab version: 10.6.5
  • Jenkins version: 2.107.3
  • Job type: Pipeline

Problem description

We have two repositories in gitlab: Repository R1 and Repository R2, and one job J1 in Jenkins.

  • Configuration of R1: a webhook refers to job J1, and the trigger manner is "Merge Request Events"
  • Configuration of J1: build trigger is "Opened Merge Request Events", pipeline is set to checkout code from a repository via git and run a Jenkinsfile inside it.

When a merge request (MR) is created in R1, J1 will be triggered. This is expected results. However, when editing the description of an open MR (which is a common operation), J1 will also be triggered in some cases. This is, instead, not expected results. Specifically, we found:

  • If J1's pipeline is configured to checkout code of R1 (same as the repository where MR is created), J1 will not be triggered (in Jenkins log, "last commit in merge request has already been built in build" is printed).
  • If J1's pipeline is configured to checkout code from another repository, for example R2, J1 will be triggered.

By checking similar isssues: #636, #633, we found it's probably caused by MergeRequestHookTriggerHandlerImpl.isLastCommitNotYetBuild().

This function checks whether the commit ID of the MR can be found in the history builds of Jenkins job or not. If the commit ID can be found, then job will not be triggered again. If the commit ID cannot be found, then job will be triggerd.

If the pipeline is configured to checkout code from another repository which is different from the repository where MR is created (for example, R2 in our scenario), then the commit IDs in Jenkins history builds are R2's commit IDs, which are almost definitely different from the MR's commit ID. So the jenkins job will be triggered.

I don't know whether this is a bug or not. Anyway, we hope that when editting description of an open MR, Jenkins jobs will not be triggered because of no code change, no matter what the pipeline configuration of the Jenkins job is.

Could anyone help to check the problem? Thanks a lot.

@omehegan
Copy link
Member

@slxiao fundamentally, I think the issue here is that GitLab fires a merge request hook when you rename an MR, which is not desirable in your case. However, if you consider that many people have a workflow where they put "WIP" in the MR title to indicate it is a work in progress, and the plugin can be configured to ignore triggers with that string in them, then you can see why there is a valid case for triggering the job on MR title changes.

Personally I don't foresee adding a feature where we allow you to ignore this on the Jenkins side. You would have to somehow check that the MR title had changed but the SHA had not, in order to skip those events. If you want to submit a PR to add this feature, I would be open to it.

@slxiao
Copy link
Author

slxiao commented Nov 19, 2018

@omehegan Thanks for your explanation. I will think about your suggestion to see whether I can submit a PR for that or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants