Trigger build if target branch changed

[Sitin]

I think it could be a good idea to trigger build if target MR branch changed to ensure that other merges weren't created regression while MR is considered by the team.

Currently builds triggered only if source branch changed.

[nickpalmer]

Great idea! I love it.

[jchristi]

:+1: I need this one

[timols]

I've been hesitant to implement this for some time now because a busy target branch would cause a significant number of builds to be triggered on the MR.

What do you think would be an appropriate way of implementing this?

[jchristi]

If the feature is undesirable in some cases, then make it a config option: "Trigger build if target branch is modified".

My use case is our mainline development branch changed from 'master' branch temporarily, and our devs are still submitting merge requests to master. When I remind them of the branch they should be using, we change the merge request, but a new jenkins build is not triggered. This problem will come up again when we switch back to using 'master' again in a few weeks.

[hicolour]

+1 this feature would be.... very, very useful

my team is performing few merge requests per day and I would like to have continuous feedback if it still could be merged to the mainstream

I think having option to disable it per jenkins job would be the best option in case of too many builds

[oker1]

:+1: this feature would be nice, a merge request is essentially code review, new changes have to be tested too.

[jchaager]

+1 This would be invaluable in situations where multiple developers are trying to finish features for a sprint.

[chwilliamson]

:+1: Some merge requests go through a life-cycle of their own and might take longer to integrate than others. Continuously building against an evolving target repository will provide up-to-date build information highlighting any regression.

[timols]

I totally agree. I think this would be useful but the implementation is non-trivial and I haven't had time to implement something like this.

Would the following workaround suffice?

1. Ensure you have a job configured for the target repository/branch
2. Trigger a build of your merge request job whenever the primary job is built

[chwilliamson]

Your proposed solution sounds good; however; you'd need to subscribe to the target_branch job built event which might be none trivial?

Here is my suggestion.

I'm referring to the gitlab API here to help.

GET /projects/:id/merge_requests

returns target_branch and source_branch like so

[
  {
    "id": 1,
    "iid": 1,
    "target_branch": "master",
    "source_branch": "test1
....}
]

My thought process is that we just need to get the current HEAD commit of target_branch and source_branch using

GET /projects/:id/repository/branches/:branch

where :branch is the target_branch or source_branch, which returns a commit hash we can use

  {
    "name": "master",
    "commit": {
      "id": "7b5c3cc8be40ee161ae89a06bba6229da1032a0c",
      "parents": [
        {
          "id": "4ad91d3c1144c406e50c7b33bae684bd6837faf8"
        }
      ],
      ....
  }

The jenkins plugin just should maintain state of the merge request id and a possible concatenation of the branch commit hashes.

GitlabMergeRequestStatus looks to track the latest commit of the source_branch for a merge request. Maybe this could be changed to track this concatenation?