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

Question

bounty到期在2天内。该问题的答案有资格获得+ 50声望赏金。Forivin正在寻找此问题的更详细的答案。

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

发布分支的管道将构建docker映像，并使用标签“ beta”进行发布。release分支的管道将构建docker映像，并使用标签“ hotfix”将其发布。

主服务器的管道只是将“ beta”重新标记为“稳定”（当发行分支已合并到主服务器中时），或将“修补程序”重新标记为“稳定”（当修补程序分支已合并到主服务器中时）。 ）。然后，它还会为该版本和gitlab中的发行版创建一个新的git标签。最终，Docker映像被部署。

当前发生以下情况：

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

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

• 管道再次开始。
• docker作业解析CI_MERGE_REQUEST_SOURCE_BRANCH_NAME，该内容现在为空，因此无法确定此合并的源分支。
• 码头工人作业失败。

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

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

我有一个master分支，应该仅通过将“ release / xxxxx”分支合并到其中或通过将“ hotfix / xxxxx”分支合并到其中来获得提交。发布分支的管道正在构建...

Answer 1

仅使用git中存储的信息：在接受合并请求之后运行时，HEAD提交应该是合并的结果，因此HEAD^2应该是合并分支的头提交。