我有一个主分支，应该只能通过将“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 作业失败。
我认为很明显，我不想在合并请求被接受之前运行所有这些作业（尤其是部署作业）。
但我想不出一种好方法，仅在合并请求被接受后在主服务器上运行管道，然后仍然能够确定源分支。
仅使用 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 设置的环境变量：
阅读后预定义变量文档页面 https://docs.gitlab.com/ee/ci/variables/predefined_variables.html，我很惊讶没有找到表明接受合并请求后触发作业的变量。
您可以查看 gitlab 的 webhooks ：合并请求事件 https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#merge-request-events;这些应该提供足够的信息来识别合并请求中涉及哪些分支after它已被接受。
[更新]你也可以使用gitlab的API，参见@BastienSander 的回答 https://stackoverflow.com/a/67298918/86072
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
