在作业规则中，您不能执行以下操作：
test_prod:
stage: deploy
environment:
name: $ENVIRONMENT
script:
- echo $ENVIRONMENT
- echo $CI_COMMIT_TAG
rules:
- if: $CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG字符串
根据这篇文章：$CI_COMMIT_TAG in "if" statemets of regular job
例如，如果您只是将新提交推送到远程，则CI_PIPELINE_SOURCE的值将为push。对于推送流水线，许多预定义变量将不存在，诸如CI_COMMIT_TAG、CI_MERGE_REQUEST_SOURCE_分支_NAME、CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME等。
但是，如果你在GitLab UI中或从git push --tags命令中创建一个Git Tag，它将创建一个Tag管道，并且CI_COMMIT_TAG等变量将存在，但CI_COMMIT_分支将不存在。
这是什么原因呢？
1条答案
按热度按时间b1zrtrql1#
这是因为git使用树结构和指针进行操作。请参考这个gitlab issue以了解更多细节，并由Drew Stachon评论：https://gitlab.com/gitlab-org/gitlab/-/issues/34578#note_381469101
不幸的是，“分支上的标记”这个概念在Git中并不存在。v0.0.2和master只是两个不同的参考，其中一个恰好指向另一个参考的修订历史中的SHA。说v0.0.2在master上，就像说master在最新的特性分支上一样。您可以想象将此逻辑构建到CI作业中，但它将涉及检测标记ref并将SHA与master的修订历史中的每个SHA进行比较，然后继续作业或退出0-ing或其他任何操作。但我强烈建议不要这样做。我猜标签v0.0.2在master的修订历史中具有特殊的意义。如果是这样的话（例如：如果您使用标签发布版本），那么我建议对在master上创建的标签采用特定的命名约定，而不要在其他地方使用它们。CI规则会在$CI_COMMIT_TAG =~ /^v\d+.\d+.\d+$/上启动某个特定的作业，而且商业规则是这些标签只在master中的提交时创建。我们在一个较小的项目上使用这个工作流程，它对我们来说效果很好。如果您使用它们来发布内容，您还应该在存储库中将标记设置为protected。如果有帮助，请告诉我，或者有什么需要我澄清的。