Question

我有n个功能分支，可以MR并合并到develop分支中。

我有3个阶段的管道：

stages: - feature-push - develop-mr-retag - develop-mr-rollout

feature-push在对功能分支（不是我们要合并到的develop分支）的任何推送上运行。它将在docker图像中测试，构建和推送应用程序，并以标记为功能分支的名称。

后两个阶段应在批准并合并合并请求后（假定源分支通过了特征推送阶段）对分支develop的提交上运行。它需要将新图像推广到一些k8s吊舱，并且需要源分支的名称才能找到正确的图像。

我想为此使用${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}，但我不认为仅在merge_requests管道上存在合并后运行的管道的变量。这些似乎是在批准MR之前触发的，我不希望这样做，因为这是部署。

这是可能的还是应该找到其他方法？

**编辑：**为了澄清，我需要在MR之前运行我的docker build，以了解它可以成功构建。如果是要合并的构建，我不想就扔掉它，这就是为什么我要在MR之前构建/推送，并在MR之后部署以前构建的映像。

Answer 1

我正在寻找相同的东西。

目前，我解析mergecommit的提交标题以提取源分支，并检查是否确实找到了该分支。这是相关代码：

CI_MERGE_REQUEST_SOURCE_BRANCH_NAME=$(sed -r "s/^Merge branch '(.*)' into .*/\1/i"<<<$CI_COMMIT_TITLE)

if [ $(git ls-remote --heads ${CI_REPOSITORY_URL} $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME | wc -l ) -ne 1 ]; then echo "Can't find source branche ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME})" && exit 1; fi

但是如果任何人都修改了默认提交标题，则将无法正常工作。

Gitlab-CI：参考源分支合并后运行部署阶段

1 个答案: