我有一个主分支,应该只能通过将“release/xxxxx”分支 merge 到其中或将“hotfix/xxxxx”分支 merge 到其中来获得提交。
发布分支的管道构建 Docker 镜像并使用标签“beta”发布它。
发布分支的管道构建一个 docker 镜像并使用标签“hotfix”发布它。
master 的管道只需将“beta”重新标记为“stable”(当发布分支已 merge 到 master 中时)或“hotfix”重新标记为“stable”(当 hotfix 分支已 merge 到 master 中时)掌握)。然后,它还会为该版本创建一个新的 git 标签,并在 gitlab 中创建一个版本。最后,docker 镜像被部署。
目前发生以下情况:
- 创建 merge 请求以将“release/xxxxx” merge 到“master”。
- 管道自动启动(在接受并 merge merge 请求之前)。
- docker 作业解析
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
变量以确定 merge 请求的源分支是发布分支。 - 然后,docker 作业将“beta”重新标记为“latest”。
- git tag 作业向项目添加版本标签和 gitlab 版本。
- 部署作业会部署 Docker 镜像。
当 merge 请求最终被接受时,会发生以下情况:
- 管道再次启动。
- docker 作业解析的
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
现在为空,因此无法确定此 merge 的源分支。 - docker 作业失败。
我认为很明显,我不想在接受 merge 请求之前运行所有这些作业(尤其是部署作业)。
但我想不出一种好方法,仅在接受 merge 请求后在主服务器上运行管道,然后仍然能够确定源分支。
最佳答案
仅使用 git 中存储的信息:
在接受 merge 请求后运行时,HEAD 提交应该是 merge 的结果,因此 HEAD^2
应该是被 merge 分支的头提交。
您可以获得以下信息:
直接指向此提交的标签:
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 后,我很惊讶没有找到表明接受 merge 请求后触发作业的变量。
您可以查看 gitlab 的 webhooks :Merge requests events ;这些应该提供足够的信息来识别 merge 请求被接受后涉及哪些分支。
[更新]你也可以使用gitlab的API,参见@BastienSander's answer
关于亚搏体育appGitLab CI : Get source branch after merge-request has been accepted,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59877180/