Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-03-14T20:56:56.353Z
Answers: 2024-03-14T20:56:56.353Z
Answers: tmpm
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2023-05-19T11:14:59.023Z
Comments: Did you find any solution for this? I want to implement the same idea in my CI but faced the same issue.
Comments: Nikita Vstovsky
Comments: CC BY-SA 4.0
Comments: 2023-11-07T15:36:16.650Z
Comments: Found anything @NikitaVstovsky or OP?
Comments: Seraf
Tags: <gitlab><cicd><gitlab-ci-runner><release-management>
Title: GitLab CI/CD get CI_MERGE_REQUEST_LABELS after merge successfully
UserDisplayName: Neneil
ThreadText: # 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 @username_1 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:
  
  1. We use merge trains
  2. We squash our commits
  
  And as pre-requisites, you need:
  
  1. A project access token (made available in CI) with at least read api access
  2. 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:
  
  ```yml
  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:
  
  ```sh
  #!/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.
  
  ```yml
  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:
  
  ```py
  branch_pattern = r"Merge branch '(?P<branch>[^']*)'"
  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](https://docs.gitlab.com/ee/api/merge_requests.html#list-project-merge-requests)
  
  
  ---
  
  