GitLab配置项：在接受合并请求后获取源分支 [英] GitLab CI: Get source branch after merge-request has been accepted

问题描述

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

发布分支的管道构建一个停靠器映像，并使用标记"beta"发布它。
发布分支的管道构建一个停靠器映像，并使用标记"hotfix"发布它。

主程序的管道只需将"beta"重新标记为"稳定"(当发布分支合并到主程序中时)，或将"hotfix"重新标记为"稳定"(当热修复程序分支合并到主程序中时)。然后它还会为该版本创建一个新的GIT标签，并在GitLab中发布一个版本。最后部署停靠机映像。

当前发生以下情况：

• 创建合并请求以将"Release/xxxxx"合并到"master"。
• 管道自动启动(在接受和合并合并请求之前)。
• 停靠器作业分析CI_MERGE_REQUEST_SOURCE_BRANCH_NAME变量以确定合并请求的源分支是发布分支。
• 停靠作业然后将"测试版"重新标记为"最新"。
• Git标记作业将版本标记和GitLab版本添加到项目中。
• 部署作业将部署坞站映像。

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

• 管道再次启动。
• 停靠作业分析现在为空的CI_MERGE_REQUEST_SOURCE_BRANCH_NAME，因此无法确定此合并的源分支。
• 驳接作业失败。

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

但我想不出一种好方法，在接受合并请求后只在主服务器上运行管道，然后仍然能够确定源分支。

推荐答案

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

在接受合并请求后运行时，头提交应该是合并的结果，因此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设置的环境变量：

阅读predefined variables doc page后，我很惊讶没有找到指示在接受合并请求后触发作业的变量。

您可以查看GitLab的网络挂钩：Merge requests events；这些网络挂钩应该提供足够的信息，以便在合并请求被接受后确定它涉及哪些分支机构。

这篇关于GitLab配置项：在接受合并请求后获取源分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！