我们可以使用阶段名称而不是作业名称来使作业依赖于 .gitlab-ci.yml 文件中的另一个作业吗?
Can we use a stage name instead of a job name to make a job dependent on another job in .gitlab-ci.yml file?
是否可以使用阶段名称而不是工作名称来使工作依赖于另一个工作?
stages:
- build
- deploy
- tests
build-job:
stage: build
deploy-feature:
stage: deploy
except:
- master
when: manual
deploy-prod:
stage: deploy
only:
- master
when: manual
test-cases:
stage: tests
dependencies: deploy-feature
也就是说,除了使用“deploy-feature”之外,我是否可以使用“deploy”来使测试用例作业同时依赖于 deploy-feature 和 deploy-prod 作业?我知道它在依赖项中不起作用,但它还有什么可以使用的吗?
P.S. 我的动机是 运行 我的测试用例作业仅在任何一个部署功能或部署产品作业完成后成功的。目前,我的“部署”工作是手动的,而“测试”工作不是,所以我的“测试用例”工作是预先执行的。
我也可以在我的测试用例工作中执行“when: manual”,并且可以 运行 在我的部署工作之后手动执行它,但对我来说,这感觉像是一种变通方法而不是解决方案。
而且我有大约 17 个“测试”工作,因此每个测试用例工作有 2 个不同的工作也不是一个可行的想法。
编辑:虽然我已经接受了一个答案,但即便如此,如果有人有更多要补充的东西或任何不同的解决方案,请分享。
从 GitLab 14.3 开始,不,您不能在任何可以使用作业名称的 keywords 中使用舞台,但是听起来您的主要问题是您的 test-cases
作业在 deploy-feature
或 deploy-prod
完成之前开始。这是因为手动作业与处于待处理状态的作业的处理方式不同,因此手动作业之后的阶段作业可以在到达阶段、运行程序可用或满足 needs
后立即开始。
您可以使用 needs
关键字控制此行为。
stages:
- build
- deploy
- tests
build-job:
stage: build
deploy-feature:
stage: deploy
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: never
when: manual
deploy-prod:
stage: deploy
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: manual
feature-test-cases:
stage: tests
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: never
needs: ['deploy-feature']
prod-test-cases:
stage: tests
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: manual
needs: ['deploy-prod']
这与您问题中的示例略有不同,因为我们将 test-cases
作业分成两部分,一个用于 'feature' 分支,另一个用于 。可以使用单个 test-cases
作业并让它“需要”两个部署作业,但两者都必须完成,鉴于我们的规则集(基于您对 [=19 的使用),这是不可能的=] 和 except
:我们不能在同一个流水线中有一个不是 main
和 main
的分支。
我更改的一件事是将 only
和 except
交换为 rules
. Rules gives us more flexibility since we can define actual if
conditionals along with OR's and AND's, and we can define multiple conditions with different outcomes. For example, one outcome might be when: always
, another when: manual
, and the last when: never
all in the same job. Also note, according to the docs:
*only* and *except* are not being actively developed. *rules* is the preferred keyword to control when to add jobs to pipelines.
当使用这样的规则时,它不仅控制作业何时或为什么手动或不手动,它甚至还控制哪些作业甚至在管道实例中。例如,对于 deploy
阶段,由于我们不能在一个管道中有 main
和“not-main”,因此在单个管道实例中只会有一个部署作业。因此,如果我们的 test-cases
作业“需要”两个部署作业,它将在运行时失败,因为它找不到一个或另一个部署作业。所以我们必须为两个管道路径设置一个 test-case
作业。
是否可以使用阶段名称而不是工作名称来使工作依赖于另一个工作?
stages:
- build
- deploy
- tests
build-job:
stage: build
deploy-feature:
stage: deploy
except:
- master
when: manual
deploy-prod:
stage: deploy
only:
- master
when: manual
test-cases:
stage: tests
dependencies: deploy-feature
也就是说,除了使用“deploy-feature”之外,我是否可以使用“deploy”来使测试用例作业同时依赖于 deploy-feature 和 deploy-prod 作业?我知道它在依赖项中不起作用,但它还有什么可以使用的吗?
P.S. 我的动机是 运行 我的测试用例作业仅在任何一个部署功能或部署产品作业完成后成功的。目前,我的“部署”工作是手动的,而“测试”工作不是,所以我的“测试用例”工作是预先执行的。 我也可以在我的测试用例工作中执行“when: manual”,并且可以 运行 在我的部署工作之后手动执行它,但对我来说,这感觉像是一种变通方法而不是解决方案。 而且我有大约 17 个“测试”工作,因此每个测试用例工作有 2 个不同的工作也不是一个可行的想法。
编辑:虽然我已经接受了一个答案,但即便如此,如果有人有更多要补充的东西或任何不同的解决方案,请分享。
从 GitLab 14.3 开始,不,您不能在任何可以使用作业名称的 keywords 中使用舞台,但是听起来您的主要问题是您的 test-cases
作业在 deploy-feature
或 deploy-prod
完成之前开始。这是因为手动作业与处于待处理状态的作业的处理方式不同,因此手动作业之后的阶段作业可以在到达阶段、运行程序可用或满足 needs
后立即开始。
您可以使用 needs
关键字控制此行为。
stages:
- build
- deploy
- tests
build-job:
stage: build
deploy-feature:
stage: deploy
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: never
when: manual
deploy-prod:
stage: deploy
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: manual
feature-test-cases:
stage: tests
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: never
needs: ['deploy-feature']
prod-test-cases:
stage: tests
rules:
- if: $CI_COMMIT_REF_NAME == 'main'
when: manual
needs: ['deploy-prod']
这与您问题中的示例略有不同,因为我们将 test-cases
作业分成两部分,一个用于 'feature' 分支,另一个用于 test-cases
作业并让它“需要”两个部署作业,但两者都必须完成,鉴于我们的规则集(基于您对 [=19 的使用),这是不可能的=] 和 except
:我们不能在同一个流水线中有一个不是 main
和 main
的分支。
我更改的一件事是将 only
和 except
交换为 rules
. Rules gives us more flexibility since we can define actual if
conditionals along with OR's and AND's, and we can define multiple conditions with different outcomes. For example, one outcome might be when: always
, another when: manual
, and the last when: never
all in the same job. Also note, according to the docs:
*only* and *except* are not being actively developed. *rules* is the preferred keyword to control when to add jobs to pipelines.
当使用这样的规则时,它不仅控制作业何时或为什么手动或不手动,它甚至还控制哪些作业甚至在管道实例中。例如,对于 deploy
阶段,由于我们不能在一个管道中有 main
和“not-main”,因此在单个管道实例中只会有一个部署作业。因此,如果我们的 test-cases
作业“需要”两个部署作业,它将在运行时失败,因为它找不到一个或另一个部署作业。所以我们必须为两个管道路径设置一个 test-case
作业。