GitLab CI：在接受合并请求后获取源分支

Question

我有一个主分支，它应该只通过将“release/xxxxx”分支合并到其中或通过将“hotfix/xxxxx”分支合并到其中来获得提交。

发布分支的管道构建一个 docker 镜像并使用标签“beta”发布它。
发布分支的管道构建一个 docker 镜像并使用标签“hotfix”发布它。

master 的管道简单地将“beta”重新标记为“stable”（当发布分支已合并到 master 中时）或“hotfix”到“stable”（当一个 hotfix 分支已合并到 master 中时）。然后它还会为该版本创建一个新的 git 标签，并在 gitlab 中发布一个版本。最后部署 docker 镜像。

目前发生以下情况：

• 创建合并请求以将“release/xxxxx”合并到“master”。
• 管道自动启动（在合并请求被接受和合并之前）。
• docker 作业解析CI_MERGE_REQUEST_SOURCE_BRANCH_NAME变量以确定合并请求的源分支是发布分支。
• 然后 docker 作业将“beta”重新标记为“latest”。
• git tag 作业向项目添加版本标签和 gitlab 版本。
• 部署作业部署 docker 镜像。

当合并请求最终被接受时，会发生以下情况：

• 管道再次启动。
• docker 作业解析CI_MERGE_REQUEST_SOURCE_BRANCH_NAME现在是空的，因此无法确定此合并的源分支。
• docker 作业失败。

我认为很明显我不想在合并请求被接受之前运行所有这些作业（尤其是部署作业）。

但是我想不出一个好方法来只在合并请求被接受后在 master 上运行管道，然后仍然能够确定源分支。

Answer 1

看来可以通过gitlab的API来实现。

这是一个卷曲示例。

  - MR_BRANCH_LAST_COMMIT_SHA=$(
      curl -s \
        --header "PRIVATE-TOKEN: $CI_PRIVATE_TOKEN" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/commits/$CI_COMMIT_SHA" |\
        jq -r '.parent_ids | del(.[] | select(. == "'$CI_COMMIT_BEFORE_SHA'")) | .[-1]'
    )
  - MR_BRANCH_NAME=$(
      curl -s \
        --header "PRIVATE-TOKEN: $CI_PRIVATE_TOKEN" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/commits/$MR_BRANCH_LAST_COMMIT_SHA/merge_requests" |\
        jq -r '.[0].source_branch'
    )

我在这里找到了解决方法： https://forum.gitlab.com/t/run-job-in-ci-pipeline-only-on-merge-branch-into-the-master-and-get-merged-branch-名称/24195/5

Answer 2

仅使用存储在 git 中的信息：

在接受合并请求后运行时，HEAD 提交应该是合并的结果，因此HEAD^2应该是合并分支的头部提交。

您可以获得以下信息：

• 直接指向这次提交的标签：

  git tag --points-at HEAD^2
  

• 直接指向此提交的分支：

  git branch --points-at HEAD^2    # for local branches
  git branch -r --points-at HEAD^2 # for remote branches
  

• 包含此提交的分支：

  git branch --contains HEAD^2    # for local branches
  git branch -r --contains HEAD^2 # for remote branches
  

使用 gitlab 设置的环境变量：

在阅读了预定义变量文档页面后，我很惊讶没有找到表明在接受合并请求后触发作业的变量。

您可以查看 gitlab 的 webhooks ：合并请求事件；这些应该提供足够的信息来识别合并请求被接受后涉及哪些分支。