我有一个master分支,应该仅通过将“ release / xxxxx”分支合并到其中或将“ hotfix / xxxxx”分支合并到其中来获得提交。
release分支的管道将构建docker映像并使用标签“ beta”发布。
release分支的管道将构建docker映像并使用标签“ hotfix”发布。
master的管道只是将“ beta”重新标记为“ stable”(当一个发行分支已合并到master中),或者将“ hotfix”重新标记为“ stable”(当一个hotfix分支已合并到主)。然后,它还会为该版本和gitlab中的发行版创建一个新的git标签。最终,Docker映像被部署。
当前发生以下情况:
- 已创建合并请求,以将“ release / xxxxx”合并到“ master”中。
- 管道自动启动(在合并请求被接受和合并之前)。
- docker作业解析
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
变量,以确定合并请求的源分支是发布分支。 - 然后,docker作业将“ beta”重新标记为“最新”。
- git标签作业将版本标签和gitlab版本添加到项目中。
- 部署作业将部署docker映像。
最终接受合并请求时,会发生以下情况:
- 管道再次启动。
- 码头工人作业解析
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
,该作业现在为空,因此无法确定该合并的源分支。 - 泊坞窗作业失败。
我认为很明显,在合并请求被接受之前,我不想运行所有这些作业(尤其是部署作业)。
但是我想不出一种好方法,仅在接受合并请求之后才能够在主服务器上运行管道,然后仍然能够确定源分支。