gitlab--job 作业运行控制 tag、when、allow_failure、retry、timeout、parallel

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: gitlab--job 作业运行控制 tag、when、allow_failure、retry、timeout、parallel

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/Njob_name N/N依次命名

stages: # 指定运行的顺序
  - test
  - deploy
deploy:
  tags:
    - k8s
  stage: deploy
  retry:
  parallel: 5 # 要并行运行的作业实例数
  script:
    - echo "我是部署阶段" # 这里我写错了
test:
  stage: test
  script:
    - echo "我是测试阶段"

可以看到运行结果如下


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
存储 Kubernetes 数据库
小笔记:关于 gitlab 运行 gitlab-ctl reconfigure 后数据清空(gitlab数据备份与恢复)
小笔记:关于 gitlab 运行 gitlab-ctl reconfigure 后数据清空(gitlab数据备份与恢复)
855 0
|
存储
gitlab--运行流水线、设置 tags、设置 pipeline 状态、添加徽章
gitlab--运行流水线、设置 tags、设置 pipeline 状态、添加徽章
|
存储 Kubernetes 安全
gitlab小笔记:关于 gitlab 运行 `gitlab-ctl reconfigure` 数据清空(gitlab数据备份与恢复)
gitlab小笔记:关于 gitlab 运行 `gitlab-ctl reconfigure` 数据清空(gitlab数据备份与恢复)
1030 1
关于gitlab 项目没有按照指定的runners运行报错
关于gitlab 项目没有按照指定的runners运行报错
关于gitlab 项目没有按照指定的runners运行报错
|
API 调度
Gitlab----Pipline流水线语法tags、allow_failure、when、timeout、retry、parallel
Gitlab----Pipline流水线语法tags、allow_failure、when、timeout、retry、parallel
1034 0
Gitlab----Pipline流水线语法tags、allow_failure、when、timeout、retry、parallel
|
Docker 容器
Docker 运行gitlab官方文档
官方文档: https://hub.docker.com/r/beginor/gitlab-ce/ sudo mkdir -p /mnt/sda1/gitlab/etc sudo mkdir -p /mnt/sda1/gitlab/log sudo mkdir -p /mnt/sda1/gitla.
1645 0
|
持续交付 调度 jenkins
GitLab-CI持续集成(CI)的介绍与运行机制
 GitLab持续集成(CI)的介绍与运行机制 GitLab-CI GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jenkins)。
2648 0
|
消息中间件 关系型数据库 Docker
docker的下载安装和运行gitlab、rabbitmq的方式
1、下载安装: docker toolbox windows下载:https://www.docker.com/products/docker-toolbox 下载后控制台执行命令:docker-machine create –engine-registry-mirror=”https://s0iielsh.
1601 0
|
3月前
|
Shell Docker 容器
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner
GitlabCI学习笔记之一:安装Gitlab和GitLabRunner