In GitLab CI, is there a variable for a Merge Request's target branch?

Question

In my pipeline, I'd like to have a job run only if the Merge Requests target branch is a certain branch, say master or release.

Is this possible?

I've read through https://docs.gitlab.com/ee/ci/variables/ and unless I missed something, I'm not seeing anything that can help.

score 30 · Answer 1 · edited Nov 08 '21 at 15:23

Update: 2019-03-21

GitLab has variables for merge request info since version 11.6 (https://docs.gitlab.com/ce/ci/variables/ see the variables start with CI_MERGE_REQUEST_). But, these variables are only available in merge request pipelines.(https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html)

To configure a CI job for merge requests, we have to set:

only: 
  - merge_requests

And then we can use CI_MERGE_REQUEST_* variables in those jobs.

The biggest pitfall here is only: merge_request has complete different behavior from normal only/except parameters.

usual only/except parameters: (https://docs.gitlab.com/ce/ci/yaml/README.html#onlyexcept-basic)

only defines the names of branches and tags for which the job will run.

except defines the names of branches and tags for which the job will not run.

only: merge_request: (https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html#excluding-certain-jobs)

The behavior of the only: merge_requests parameter is such that only jobs with that parameter are run in the context of a merge request; no other jobs will be run.

I felt hard to reorganize jobs to make them work like before with only: merge_request exists on any job. Thus I'm still using the one-liner in my original answer to get MR info in a CI job.

Original answer:

No.

But GitLab have a plan for this feature in 2019 Q2: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#final-assumptions

Currently, we can use a workaround to achieve this. The method is as Rekovni's answer described, and it actually works.

There's a simple one-liner, get the target branch of an MR from the current branch:

script: # in any script section of gitlab-ci.yml
  - 'CI_TARGET_BRANCH_NAME=$(curl -LsS -H "PRIVATE-TOKEN: $AWESOME_GITLAB_API_TOKEN" "https://my.gitlab-instance.com/api/v4/projects/$CI_PROJECT_ID/merge_requests?source_branch=$CI_COMMIT_REF_NAME" | jq --raw-output ".[0].target_branch")'

Explanation:

CI_TARGET_BRANCH_NAME is a newly defined variable which stores resolved target branch name. Defining a variable is not necessary for various usage.

AWESOME_GITLAB_API_TOKEN is the variable configured in repository's CI/CD variable config. It is a GitLab personal access token(created in User Settings) with api scope.

About curl options: -L makes curl aware of HTTP redirections. -sS makes curl silent(-s) but show(-S) errors. -H specifies authority info accessing GitLab API.

The used API could be founded in https://docs.gitlab.com/ce/api/merge_requests.html#list-project-merge-requests. We use the source_branch attribute to figure out which MR current pipeline is running on. Thus, if a source branch has multiple MR to different target branch, you may want to change the part after | and do your own logic.

About jq(https://stedolan.github.io/jq/), it's a simple CLI util to deal with JSON stuff(what GitLab API returns). You could use node -p or any method you want.

How would you then use that to decide whether to conditionally run the script or not? — geoidesic, Sep 01 '22 at 09:52

score 18 · Answer 2 · answered Jan 08 '19 at 15:39

Because of the new env variables in 11.6 $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME and $CI_MERGE_REQUEST_TARGET_BRANCH_NAME jobs can be included or excluded based on the source or target branch.

Using the only and except (complex) expressions, we can build a rule to filter merge requests. For a couple examples:

Merge request where the target branch is master:

only:
    refs:
        - merge_requests
    variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Merge request except if the source branch is master or release:

only:
    - merge_requests
except:
    variables:
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "master"
        - $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "release"

If you want to use multiple refs (let's say merge_requests and tags) and multiple variables, the refs will be OR'd, the variables will be OR'd, and the result will be AND'd:

If any of the conditions in variables evaluates to truth when using only, a new job is going to be created. If any of the expressions evaluates to truth when except is being used, a job is not going to be created.

If you use multiple keys under only or except, they act as an AND. The logic is:
(any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)

Variable expressions are also quite primitive, only supporting equality and (basic) regex. Because the variables will be OR'd you cannot specify both a source and target branch as of gitlab 11.6, just one or the other.

score 6 · Answer 3 · answered Jan 01 '19 at 19:52

6

As of GitLab 11.6, there is CI_MERGE_REQUEST_TARGET_BRANCH_NAME.

answered Jan 01 '19 at 19:52

Gajus

69,002
70
275
438

score 3 · Answer 4 · answered Oct 12 '18 at 07:47

If this is what you're really after, there could be an extremely convoluted way (untested) you could achieve this using the merge request API and CI variables.

With a workflow / build step something like:

Create merge request from feature/test to master
Start a build
Using the API (in a script), grab all open merge requests from the current project using CI_PROJECT_ID variable, and filter by source_branch and target_branch.
If there is a merge request open with the source_branch and target_branch being feature/test and master respectively, continue with the build, otherwise just skip the rest of the build.

For using the API, I don't believe you can use the CI_JOB_TOKEN variable to authenticate, so you'll probably need to create your own personal access token and store it as a CI variable to use in the build job.

Hope this helps!

score 2 · Answer 5 · answered May 19 '22 at 14:48

2

Another example, but using rules:

  rules:
    # pipeline should run on merge request to master branch
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'master'
      when: always
    # pipeline should run on merge request to release branch
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'release'
      when: always
    - when: never

answered May 19 '22 at 14:48

Daniel Andrzejewski

470
4
10

`$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'target'` would be sufficient since it would == '' if it weren't a merge request – Brandon Kauffman Jan 25 '23 at 15:55

score 1 · Accepted Answer · edited Mar 11 '21 at 14:44

1

Gitlab CI is agnostic of Merge Requests (for now). Since the pipeline runs on the origin branch you will not be able to retrieve the destination.

edited Mar 11 '21 at 14:44

E_net4

27,810
13
101
139

answered Oct 11 '18 at 08:11

djuarezg

2,307
2
20
34

In GitLab CI, is there a variable for a Merge Request's target branch?

6 Answers6

Linked