我有一个master分支,应该仅通过将“ release / xxxxx”分支合并到其中或将“ hotfix / xxxxx”分支合并到其中来获得提交。
release分支的管道将构建docker映像并使用标签“ beta”发布。
release分支的管道将构建docker映像并使用标签“ hotfix”发布。
master的管道只是将“ beta”重新标记为“ stable”(当一个发行分支已合并到master中),或者将“ hotfix”重新标记为“ stable”(当一个hotfix分支已合并到主)。然后,它还会为该版本和gitlab中的发行版创建一个新的git标签。最终,Docker映像被部署。
当前发生以下情况:
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
变量,以确定合并请求的源分支是发布分支。最终接受合并请求时,会发生以下情况:
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
,该作业现在为空,因此无法确定该合并的源分支。我认为很明显,在合并请求被接受之前,我不想运行所有这些作业(尤其是部署作业)。
但是我想不出一种好方法,仅在接受合并请求之后才能够在主服务器上运行管道,然后仍然能够确定源分支。
答案 0 :(得分:2)
仅使用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设置的环境变量:
在阅读predefined variables doc page之后,我很惊讶地没有找到表明在接受合并请求后触发了作业的变量。
您可以查看gitlab的webhooks:Merge requests events;这些应该提供足够的信息,以在合并请求 被接受之后,确定涉及到哪些分支。
答案 1 :(得分:0)
好像可以通过gitlab的API来实现。
这是一个卷曲示例。
- MR_BRANCH_LAST_COMMIT_SHA=$(
curl -s \
--header "PRIVATE-TOKEN: $CI_PRIVATE_TOKEN" \
"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/commits/$CI_COMMIT_SHA" |\
jq -r '.parent_ids | del(.[] | select(. == "'$CI_COMMIT_BEFORE_SHA'")) | .[-1]'
)
- MR_BRANCH_NAME=$(
curl -s \
--header "PRIVATE-TOKEN: $CI_PRIVATE_TOKEN" \
"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/commits/$MR_BRANCH_LAST_COMMIT_SHA/merge_requests" |\
jq -r '.[0].source_branch'
)