【发布时间】:2020-05-09 15:27:06
【问题描述】:
我有一个 master 分支,它应该只能通过将“release/xxxxx”分支合并到其中或将“hotfix/xxxxx”分支合并到其中来获得提交。
发布分支的管道构建一个 docker 镜像并使用标签“beta”发布它。
发布分支的管道构建一个 docker 镜像并使用标签“hotfix”发布它。
master 的管道只需将“beta”重新标记为“stable”(当发布分支已合并到 master 中时)或“hotfix”到“stable”(当 hotfix 分支已合并到掌握)。然后它还会为该版本创建一个新的 git 标签并在 gitlab 中发布。最终部署 docker 镜像。
目前发生以下情况:
- 创建合并请求以将“release/xxxxx”合并到“master”。
- 管道自动启动(在合并请求被接受和合并之前)。
- docker 作业解析
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME变量以确定合并请求的源分支是发布分支。 - 然后 docker 作业将“beta”重新标记为“latest”。
- git tag 作业为项目添加版本标签和gitlab release。
- 部署作业部署 docker 映像。
当最终接受合并请求时,会发生以下情况:
- 管道再次启动。
- docker 作业解析
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME现在为空,因此无法确定此合并的源分支。 - docker 作业失败。
我认为很明显我不想在合并请求被接受之前运行所有这些作业(尤其是部署作业)。
但我想不出一个好方法,只在接受合并请求后在主服务器上运行管道,然后仍然能够确定源分支。
【问题讨论】:
-
你能分享你的
gitlab-ci.yml文件吗? -
我的实际
.gitlab-ci.yml是一个大杂烩,每个分支最多处理 13 个工作,而且我的问题中提到的 3 个分支要多得多。更不用说它包含来自其他非公共项目的一堆文件,使用自定义非公共 docker 图像并严重依赖于组和项目级别设置的环境变量的事实。我无法分享所有这些,单独的 .gitlab-ci.yml 对任何人都无济于事。 -
我了解您的情况,但我们很难假设您的配置为管道和部署都高度依赖 yml 文件。
-
你找到解决办法了吗?
标签: git merge gitlab gitlab-ci branching-and-merging