由网友(五行缺德)分享简介：我有一个主分支，它应该只通过将"Release/xxxxx"分支合并到其中或通过将"hotfix/xxxxx"分支合并到其中来获得提交。发布分支的管道构建一个停靠器映像，并使用标记"beta"发布它。发布分支的管道构建一个停靠器映像，并使用标记"hotfix"发布它。主程序的管道只需将"beta"重新标记为"稳定"(...

我有一个主分支，它应该只通过将"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；这些网络挂钩应该提供足够的信息，以便在合并请求被接受后确定它涉及哪些分支机构。