job 作业设置
定义一个 job
的时候,一般定义哪些关键字呢?作业在哪个 Runner
运行?作业属于流水线的哪个阶段?这个 job
要做什么?
stages: - test - deploy variables: # 全局变量 VERSIONS: "1.32.1" RUNNER_TAG: "k8s" # 定义一个 Runner 的 tag,其他地方引用就可以了 deploy1: # job 的名称 tags: # job 要运行 Runner 的 tag - ${RUNNER_TAG} # 引用变量 - build stage: deploy # 运行阶段 before_script: - echo "job 运行之前要执行的" script: - echo "job 运行阶段执行的" after_script: - echo "job 运行之后要执行的" test1: # 没有指定要运行的 runner,就在可以运行的 runner 上选择一台运行 stage: test script: - echo "Do a test here" - echo "For example run a test suite" before_script: - echo "流水线运行之前要执行的" after_script: - echo "流水线运行之后要执行的"
tags
用于从允许运行该项目的所有 Runner
列表中选择特定的 Runner
,在 Runner
注册期间,您可以指定 Runner
的标签。
tags
可让您使用指定了标签的runner
来运行作业,此 runner 具有 ruby 和 postgres 标签
stages: # 指定运行的顺序 - test - deploy deploy: tags: # runner 要同时有这两个标签 - docker - k8s stage: deploy script: - echo "我是部署阶段" test: stage: test script: - echo "我是测试阶段"
现在我们的 runer 只有一个 k8s 的标签,看下流水线会不会运行
可以看到 test 阶段运行成功了,因为 runner 勾选了没有标签的任务也可以运行。但 deploy 阶段阻塞住了,因为没有满足该 job 的 runner
job 作业运行控制
语法关键字 |
作用 | 备注 |
allow_failure |
控制作业状态,是否允许作业失败。默认值为 false。启用后,如果作业运行失败,该作业将在用户界面中显示橙色警告 | 管道将认为作业通过,不会被阻塞 假设所有其他作业均成功,则该作业的阶段及其管道将显示相同的橙色警告。但是,关联的提交将被标记为"通过",而不会发出警告。 |
when | 根据状态控制作业运行,当前面作业成功或者失败时运行 | on_ success:前面阶段成功时执行(默认值) on_failure:前面阶段失败时执行 always:总是执行 manual:手动执行 delayed:延迟执行 never:永不执行
|
retry | 作业重新运行,遇到错误重新运行的次数 | 值为整数,等于或大于 0,但小于或等于 2 |
timeout | job 运行超时时间 | |
rules | 根据特定的变量或文件变更来控制 job 的运行 | if changes exists |
needs | job 依赖控制 | needs: ["job名称"] |
paraller | 生成多个 job,并行运行 | paraller: 5 值 2-50 之间 |
allow_failure
allow_failure 允许作业失败,默认值为 false。启用后,如果作业失败,该作业将在用户界面中显示橙色警告。但是流水线将认为该 job 成功,并且不会阻塞。假设其他所有作业均运行成功,则该 job 的阶段及其流水线将显示相同的橙色警告。但是,关联的提交将被标记为通过,而不会发出失败
我们将一个阶段写错,看 pipeline 怎么处理
stages: # 指定运行的步骤,没有指定就顺序执行 - build - deploy - test build1: # job 的名称 tags: - k8s # 运行的 runner 标签 stage: build script: - echo "Do your build here" test1: stage: test script: - echo "Do a test here" - echo "For example run a test suite" test2: stage: test script: - echo "Do another parallel test here" - echo "For example run a lint test" deploy1: tags: - k8s stage: deploy script: - ech "Do your deploy here" # 这里写错
上面我们将 deploy 阶段的脚本改错了,查看运行结果
我们发现,deploy 阶段运行失败后,后面的阶段 test 就跳过了
那我们如果想 deploy 阶段运行失败后,后面的不跳过,就可以加上 allow_failure 参数,如下
stages: # 指定运行的步骤,没有指定就顺序执行 - build - deploy - test build1: tags: - k8s stage: build script: - echo "Do your build here" test1: stage: test script: - echo "Do a test here" - echo "For example run a test suite" test2: stage: test script: - echo "Do another parallel test here" - echo "For example run a lint test" deploy1: tags: - k8s stage: deploy script: - ech "Do your deploy here" # 这里写错 allow_failure: true # 这个阶段失败不影响后面的阶段
在来查看结果,从结果我们可以看出,加上 allow_failure: true 后,某个阶段运行失败后,不会影响后面的流程。只是会加上一个橙色的警告
when
when 可以控制该流水线以什么样的方式运行,例如
- on_success:前面阶段中的所有作业都成功(或由于标记为
allow_failure
而被视为成功)时才执行作业。 这是默认值。 - on_failure:当前面阶段出现失败则执行。
- always: 执行作业,而不管先前阶段的作业状态如何,放到最后执行。总是执行。
- manual:手动执行作业,不会自动执行,需要由用户显式启动. 手动操作的示例用法是部署到生产环境. 可以从管道,作业,环境和部署视图开始手动操作。
假如在 deploy 阶段添加manual,则流水线运行到 deploy 阶段为锁定状态,需要手动点击按钮才能运行 deploy 阶段。 - delayed:延迟一定时间后执行作业,有效值
'5',10 seconds,30 minutes, 1 day, 1 week
stages: # 指定运行的步骤,没有指定就顺序执行 - build - deploy - test build1: tags: - k8s stage: build script: - echo "Do your build here" when: manual # 手动执行 test1: stage: test script: - echo "Do a test here" - echo "For example run a test suite" test2: stage: test script: - echo "Do another parallel test here" - echo "For example run a lint test" deploy1: tags: - k8s stage: deploy script: - echo "Do your deploy here" allow_failure: true # 这个阶段失败不影响后面的阶段 when: delayed # 延迟执行 start_in: "5" # 延迟 5 秒
例子二
retry
配置在失败的情况下重试作业的次数。
当作业失败并配置了retry
,将再次处理该作业,直到达到retry
关键字指定的次数。如果retry
设置为 2,并且作业在第二次运行成功(第一次重试),则不会再次重试。 retry
值必须是一个正整数,等于或大于0,但小于或等于2(最多两次重试,总共运行3次)
stages: # 指定运行的顺序 - test - deploy deploy: tags: - k8s stage: deploy retry: 2 # 最多重试 2 次,加上默认的一次,最多运行三次 script: - ech "我是部署阶段" # 这里我写错了 test: stage: test script: - echo "我是测试阶段"
查看流水线
默认情况下,将在所有失败情况下重试作业。为了更好地控制retry
哪些失败,可以是具有以下键的哈希值:
- max :最大重试次数.
- when :重试失败的案例
根据错误原因设置重试的次数。
always :# 在发生任何故障时重试(默认). unknown_failure :# 当失败原因未知时。 script_failure :# 脚本失败时重试。 api_failure :# API失败重试。 stuck_or_timeout_failure :# 作业卡住或超时时。 runner_system_failure :# 运行系统发生故障。 missing_dependency_failure: # 如果依赖丢失。 runner_unsupported :# Runner不受支持。 stale_schedule :# 无法执行延迟的作业。 job_execution_timeout :# 脚本超出了为作业设置的最大执行时间。 archived_failure :# 作业已存档且无法运行。 unmet_prerequisites :# 作业未能完成先决条件任务。 scheduler_failure :# 调度程序未能将作业分配给运行scheduler_failure。 data_integrity_failure :# 检测到结构完整性问题。
例如
stages: # 指定运行的顺序 - test - deploy deploy: tags: - k8s stage: deploy retry: max: 2 # 最多重试 2 次 when: - script_failure # 只有脚本失败的时候才会重试 script: - ech "我是部署阶段" # 这里我写错了 test: stage: test script: - echo "我是测试阶段"
查看流水线
timeout 超时
特定作业配置超时,作业级别的超时可以超过项目级别的超时,但不能超过 Runner 特定的超时
项目设置流水线超时时间
超时定义了作业可以运行的最长时间(以分钟为单位)。 这可以在项目的"设置">" CI / CD">"流水线通用设置"下进行配置 。 默认值为 1 小时
runner 超时时间
此类超时(如果小于项目定义的超时 )将具有优先权。此功能可用于通过设置大超时(例如一个星期)来防止Shared Runner被项目占用。未配置时,Runner将不会覆盖项目超时
job 的超时时间
stages: # 指定运行的顺序 - test - deploy deploy: tags: - k8s stage: deploy retry: timeout: 3 hours 30 minutes # job 的超时时间 script: - echo "我是部署阶段" test: stage: test script: - echo "我是测试阶段"
此功能如何工作:
- 运行程序超时大于项目超时:runner超时设置为24小时,项目的CI / CD超时设置为**2小时。该工作将在2小时后超时。
- 未配置运行程序超时:runner不设置超时时间,项目的CI / CD超时设置为2小时。该工作将在2小时后超时。
- 运行程序超时小于项目超时:runner超时设置为30分钟,项目的CI / CD超时设置为2小时。工作在30分钟后将超时
parallel
配置要并行运行的作业实例数,此值必须大于或等于 2 并且小于或等于 50。
这将创建 N 个并行运行的同一作业实例. 它们从job_name 1/N
到job_name N/N
依次命名
stages: # 指定运行的顺序 - test - deploy deploy: tags: - k8s stage: deploy retry: parallel: 5 # 要并行运行的作业实例数 script: - echo "我是部署阶段" # 这里我写错了 test: stage: test script: - echo "我是测试阶段"
可以看到运行结果如下