<p>My team had the exact same use-case. Our merge strategy is the following:</p>
<ol>
<li>We use merge trains</li>
<li>We squash our commits</li>
</ol>
<p>And as pre-requisites, you need:</p>
<ol>
<li>A project access token (made available in CI) with at least read api access</li>
<li>Scoped labels for the kind of release (obviously)</li>
</ol>
<p>Based on these conditions, you can solve this problem by inspecting the commit message in your commit stage, extract out the branch name from the commit, and use that branch name to hit the Gitlab API to get the merge request's label.</p>
<p>We have two stages in our gitlab-ci:</p>
<pre class="lang-yml prettyprint-override"><code>verify_tags:
  stage: lint
  script:
    - sh build-scripts/verify-merge-request-labels.sh
  rules:
    - if: '$CI_PIPELINE_SOURCE == &quot;merge_request_event&quot;'
</code></pre>
<p>this stage verifies that merge requests have labels. If they don't, they can't be merged. The <code>verify-merge-request-labels.sh</code> script is pretty simple:</p>
<pre class="lang-sh prettyprint-override"><code>#!/bin/sh
BUMP_VERSION_TYPE=$(echo &quot;$CI_MERGE_REQUEST_LABELS&quot; | sed -E 's/.*bump version::(major|minor|patch).*/\1/')
case $BUMP_VERSION_TYPE in
    major|minor|patch)
        echo &quot;Detected semver part $BUMP_VERSION_TYPE&quot;
        ;;
    *)
        echo &quot;Could not parse semver part out of $CI_MERGE_REQUEST_LABELS. Make sure to add a \`bump version\` label to your merge request.&quot;
        exit 1
        ;;
esac
</code></pre>
<p>The second stage actually gets ran when the branch is getting merged in.</p>
<pre class="lang-yml prettyprint-override"><code>increment_version:
  stage: release
  image: python:3.9
  before_script:
    - git remote set-url origin &quot;https://gitlab-ci-token:${RUNNER_TOKEN}@${YOUR_GIT_HOST}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}.git&quot;
    - git config --global user.email &quot;${GITLAB_USER_EMAIL}&quot;
    - git config --global user.name &quot;${GITLAB_USER_NAME}&quot;
    - poetry install --only dev
  script:
    - poetry run bumpver update $(python build-scripts/determine-bumpver-semver-flag.py)
    - git push -o ci.skip origin $(git tag) HEAD:${CI_COMMIT_REF_NAME}
  rules:
    - if: '$CI_COMMIT_BRANCH == &quot;main&quot;'
</code></pre>
<p>The second script is a bit more complex (and long) so I won't share its entirety, but its snippets (in python using <code>requests</code>) are as follows:</p>
<pre class="lang-py prettyprint-override"><code>branch_pattern = r&quot;Merge branch '(?P&lt;branch&gt;[^']*)'&quot;
source_branch = re.search(branch_pattern, os.environ[&quot;CI_COMMIT_TITLE&quot;]).group(&quot;branch&quot;)
# Get original merge request corresponding to source branch
query_params = {&quot;source_branch&quot;: source_branch}
url = f&quot;{os.environ['CI_API_V4_URL']}/projects/{os.environ['CI_PROJECT_ID']}/merge_requests&quot;

r = requests.get(
    url=url,
    params=query_params,
    headers={&quot;Authorization&quot;: f&quot;Bearer {os.environ['RUNNER_TOKEN']}&quot;},
)
labels = r.json()[0][&quot;labels&quot;]
</code></pre>
<p>The API reference is <a href="https://docs.gitlab.com/ee/api/merge_requests.html#list-project-merge-requests" rel="nofollow noreferrer">here</a></p>

CC BY-SA 4.0
2024-03-14T20:56:56.353Z
2024-03-14T20:56:56.353Z
tmpm
<p>I know that the <a href="https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines" rel="nofollow noreferrer">docs</a> say, that the variable <code>CI_MERGE_REQUEST_LABELS</code> is available if pipeline is a merge request pipeline and the MR is open.</p>
<p>My dream was it to label my MR's with <code>patch</code>, <code>minor</code> or <code>major</code> labels. When merge the MR, my pipline, for e.g. <code>master</code> branch, gets triggered and in the jobs of that pipeline I want to use the label.</p>
<p>In the job I want to do some Version-Number stuff with the label information. We use this for other connected services.</p>
<p>Does someone has an idea how to get access to the labels or has another approach how to get information about the kind of the release (<code>major</code>, <code>minor</code>, <code>patch</code>)?</p>

CC BY-SA 4.0
2023-05-19T11:14:59.023Z
Did you find any solution for this? I want to implement the same idea in my CI but faced the same issue.
Nikita Vstovsky
CC BY-SA 4.0
2023-11-07T15:36:16.650Z
Found anything @NikitaVstovsky or OP?
Seraf
<gitlab><cicd><gitlab-ci-runner><release-management>
GitLab CI/CD get CI_MERGE_REQUEST_LABELS after merge successfully
Neneil
# GitLab CI/CD get CI_MERGE_REQUEST_LABELS after merge successfully

(Asked by: username_0 on 2021-09-14)

I know that the [docs](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#predefined-variables-for-merge-request-pipelines) say, that the variable `CI_MERGE_REQUEST_LABELS` is available if pipeline is a merge request pipeline and the MR is open.

My dream was it to label my MR's with `patch`, `minor` or `major` labels. When merge the MR, my pipline, for e.g. `master` branch, gets triggered and in the jobs of that pipeline I want to use the label.

In the job I want to do some Version-Number stuff with the label information. We use this for other connected services.

Does someone has an idea how to get access to the labels or has another approach how to get information about the kind of the release (`major`, `minor`, `patch`)?

**Tags:** gitlab, cicd, gitlab-ci-runner, release-management

> **Comments:**
> **username_1**: Did you find any solution for this? I want to implement the same idea in my CI but faced the same issue.  
> **username_2**: Found anything @NikitaVstovsky or OP?  

---

## 1 answers

### Answer by username_3 on 2024-03-14. Score: 2

My team had the exact same use-case. Our merge strategy is the following:

We use merge trains
We squash our commits

And as pre-requisites, you need:

A project access token (made available in CI) with at least read api access
Scoped labels for the kind of release (obviously)

Based on these conditions, you can solve this problem by inspecting the commit message in your commit stage, extract out the branch name from the commit, and use that branch name to hit the Gitlab API to get the merge request's label.
We have two stages in our gitlab-ci:
verify_tags:
  stage: lint
  script:
    - sh build-scripts/verify-merge-request-labels.sh
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

this stage verifies that merge requests have labels. If they don't, they can't be merged. The verify-merge-request-labels.sh script is pretty simple:
#!/bin/sh
BUMP_VERSION_TYPE=$(echo "$CI_MERGE_REQUEST_LABELS" | sed -E 's/.*bump version::(major|minor|patch).*/\1/')
case $BUMP_VERSION_TYPE in
    major|minor|patch)
        echo "Detected semver part $BUMP_VERSION_TYPE"
        ;;
    *)
        echo "Could not parse semver part out of $CI_MERGE_REQUEST_LABELS. Make sure to add a \`bump version\` label to your merge request."
        exit 1
        ;;
esac

The second stage actually gets ran when the branch is getting merged in.
increment_version:
  stage: release
  image: python:3.9
  before_script:
    - git remote set-url origin "https://gitlab-ci-token:${RUNNER_TOKEN}@${YOUR_GIT_HOST}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}.git"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
    - git config --global user.name "${GITLAB_USER_NAME}"
    - poetry install --only dev
  script:
    - poetry run bumpver update $(python build-scripts/determine-bumpver-semver-flag.py)
    - git push -o ci.skip origin $(git tag) HEAD:${CI_COMMIT_REF_NAME}
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

The second script is a bit more complex (and long) so I won't share its entirety, but its snippets (in python using requests) are as follows:
branch_pattern = r"Merge branch '(?P[^']*)'"
source_branch = re.search(branch_pattern, os.environ["CI_COMMIT_TITLE"]).group("branch")
# Get original merge request corresponding to source branch
query_params = {"source_branch": source_branch}
url = f"{os.environ['CI_API_V4_URL']}/projects/{os.environ['CI_PROJECT_ID']}/merge_requests"

r = requests.get(
    url=url,
    params=query_params,
    headers={"Authorization": f"Bearer {os.environ['RUNNER_TOKEN']}"},
)
labels = r.json()[0]["labels"]

The API reference is here


---

