我们正在尝试在我们的机构 GitLab 中创建一个良好的合并列车设置。 目前,我们的管道中有一些运行昂贵的模糊测试的作业。这些作业不应在每次推送时运行,但应在合并之前运行,并且应该可以手动激活它们。
目前这些作业被标记为通用管道的手动作业。
fuzzy-tests:
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
when: never
- if: >
$CI_COMMIT_TAG ||
$CI_COMMIT_BRANCH == 'main' ||
$CI_COMMIT_BRANCH == 'release/*' ||
$PUBLISH_DEV_VERSION
when: on_success
- when: manual
它们应该作为合并列车管道的一部分自动运行,因为当合并列车运行时,我们不想启动手动作业。有没有办法作为
rules
条目的一部分来确定作业的上下文是否是合并列车管道?
如果没有,是否有一个好方法来确保
fuzzy-tests
在每次合并之前至少运行一次,可以按需运行,而不是在合并请求的每次更改时运行?
它们应该作为合并列车管道的一部分自动运行[...]有没有办法作为规则条目的一部分来确定作业的上下文是否是合并列车管道?
您可以使用
CI_MERGE_REQUEST_EVENT_TYPE
变量。根据文档,此变量包含:
合并请求的事件类型。可以是
、detached
或merged_result
。merge_train
因此,也许您在相关部分设置工作规则来使用此变量,如下所示:
fuzzy-tests:
rules:
- if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
when: on_success
# ...
还请记住,在合并请求管道上,
CI_COMMIT_BRANCH
不会出现。如文档中所述(添加了重点):
提交分支名称。在分支管道中可用,包括默认分支的管道。 不适用于合并请求管道或标记管道。
如果您需要使用具有取决于分支/标签命名的复合子句的规则,同时还在分支管道以外的上下文中,您可以考虑使用
CI_COMMIT_REF_NAME
来代替,它在更多上下文中可用,或更明确, CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
对于合并请求。