.gitlab-ci.yml配置详解

tags: [转载,gitlab]
categories: [CICD]

前言

转载了关于.gitlab-ci.yml文件的配置参数详解

.gitlab-ci.yml 配置参数

使用说明

script

是作业中唯一必须的关键字参数，是运行器需要执行的脚本

build1:
  script:
    - echo "Do your build here"
    - uname -a

image

指定使用Docker镜像

services

指定使用Docker镜像服务

before_script

用于定义在所有作业之前需要执行的命令，比如更新代码、安装依赖、打印调试信息之类的事情
**

after_script

用于定义在所有作业(即使失败)之后需要执行的命令，比如清空工作空间

| 注意
before_script和script在一个上下文中是串行执行的，after_script是独立执行的，即after_script与before_script/script的上下文环境不同。
- after_script会将当前工作目录设置为默认值。
- 由于after_script是分离的上下文，在after_script中无法看到在before_script和script中所做的修改:
> - 在before_script和script中的命名别名、导出变量，对after_script不可见；

• before_script和script在工作树之外安装的软件，对after_script不可见。

• 你可以在作业中定义before_script，after_script，也可以将其定义为顶级元素，定义为顶级元素将为每一个任务都执行相应阶段的脚本或命令。作业级会覆盖全局级的定义
  | | | | —- | —- | —- | | |

stages

stages 定义流水线全局可使用的阶段，阶段允许有灵活的多级管道，阶段元素的排序定义了作业执行的顺序。

• 相同 stage 阶段的作业并行运行。
• 默认情况下，上一阶段的作业全部运行成功后才执行下一阶段的作业。
• 默认有三个阶段， build 、test 、deploy 三个阶段，即 构建 、测试 、部署 。
• 如果一个作业未定义 stage 阶段，则作业使用 test 测试阶段。
• 默认情况下，任何一个前置的作业失败了，commit提交会标记为failed并且下一个stages的作业都不会执行

allow_failure

• allow_failure 可以用于当你想设置一个作业失败的之后并不影响后续的CI组件的时候。失败的作业不会影响到commit提交状态。
• 如果允许失败的作业失败了，则相应的作业会显示一个黄色的警告，但对流水线成功与否不产生影响。

下面的这个例子中，job1和job2将会并列进行，如果job1失败了，它也不会影响进行中的下一个阶段，因为这里有设置了 allow_failure: true

job1:
  stage: test
  script:
  - execute_script_that_will_fail
  allow_failure: true
job2:
  stage: test
  script:
  - execute_script_that_will_succeed
job3:
  stage: deploy
  script:
  - deploy_to_staging

when

when 关键字用于实现在作业失败时或发生故障时运行的作业
when 可以设置以下值：
on_success ：只有前面的阶段的所有作业都成功时才执行，这是默认值。
on_failure ：当前面阶段的作业至少有一个失败时才执行。
always : 无论前面的作业是否成功，一直执行本作业。
manual ：手动执行作业，作业不会自动执行，需要人工手动点击启动作业。
delayed : 延迟执行作业，配合 start_in 关键字一起作用， start_in 设置的值必须小于或等于1小时，start_in 设置的值示例： 10 seconds 、 30 minutes 、 1 hour ，前面的作业结束时计时器马上开始计时

stage:
    - build
  - cleanup_build
  - test
  - deploy
  - cleanup
build_job:
  stage: build
  script:
    - make build
cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure
test_job:
  stage: test
  script:
    - make test
deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual
cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always

说明：

• 只有在 build_job 构建作业失败时，才会执行 cleanup_build_job 作业。
• 需要在GitLab Web界面手动点击，才能执行 deploy_job 部署作业。
• 无论之前的作业是否成功还是失败，cleanup_job 清理作业一直会执行

cache

GitLab Runner v0.7.0 引入 cache 缓存机制。
cache 缓存机制，可以在全局设置或者每个作业中设置。
从 GitLab 9.0 开始， cache 缓存机制，可以在不同的的流水线或作业之间共享数据。
从 GitLab 9.2 开始， 在 artifacts 工件之前恢复缓存。
cache 缓存机制用于指定一系列的文件或文件夹在不同的流水线或作业之间共享数据，仅能使用项目工作空间( project workspace )中的路径作为缓存的路径。
如果 ``cache 配置的路径是作业工作空间外部，则说明配置是全局的缓存，所有作业共享

artifacts

• artifacts 用于指定在作业成功、失败、或者一直等状态下时，一系列的文件或文件夹附加到作业中。artifacts 可以称为 工件``或者 ``归档文件 。
• 作业完成后，工件被发送到GitLab，可以在GitLab Web界面下载。
• 默认情况下，只有成功的作业才会生成工件。
• 并不是所有的 executor 执行器都支持工件

variables

• 在 .gitlab-ci.yml 配置文件中可以通过 variables 关键字配置全局变量或者作业级的局部变量。
• 当 variables 关键字使用在作业层级时，它会覆盖全局变量或预定义变量。
• 可以在 variables 关键字中定义非敏感性配置。
• 全局变量可以在各个作业中作业，而作业级别的局部变量只能在该作业中使用。
• 可以在GitLab WEB界面定义一些敏感性配置变量，或者可能变动的变量。
• 在 script 中使用 export 可以导出当前可用的变量信息。
• 作业内部修改全局变量只对当前作用生效，不会影响其他作业。
• 可以使用赋值语句对全局变量或局部变量进行重新赋值

only 和 except

only 和 except 用于在创建作业时对作业的限制策略。

• only 定义了哪些分支或标签(branches and tags)的作业会运行
• except 定义了哪些分支或标签(branches and tags)的作业不会运行

下面是策略规则：

• only 和 except 可同时使用，如果在一个作业中同时定义了 only 和 except ，则同时 only except 进行过滤(注意，不是忽略 except 条件) 。
• only 和 except 可以使用正则表达式。
• only 和 except 允许指定用于过滤forks作业的存储库路径。
• only 和 except 中可以使用特殊的关键字，如 branches 、 tags 、 api 、 external 、 pipelines 、 pushes 、 schedules 、 triggers 、 web 、 merge_requests 、 chats 等。

only 和 except 中可以使用特殊的关键字：

tags

tags 关键字用于指定 GitLab Runner 运行器使用哪一个运行器来执行作业

运行器标签可用于定义不同平台上运行的作业，如 Mac OS X Runner 使用 osx 标签， Windows Runner 使用 windows 标签，而 Linux Runner 使用 linux 标签

转载自