GitLab CI/CD：.gitlab-ci.yml 文件常用参数小结

喜欢打篮球的普通人

已于 2023-09-24 22:24:54 修改

阅读量1.5k

点赞数 1

分类专栏： gitlab 文章标签： git github

于 2023-09-24 10:58:44 首次发布

本文链接：https://blog.csdn.net/u011436427/article/details/133233979

版权

gitlab 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

文章目录

一、.gitlab-ci.yml 文件作用
二、一个简单的.gitlab-ci.yml 文件示例
三、gilab的CICD预定义变量
四、gilab自定义变量

一、.gitlab-ci.yml 文件作用

可以定义跑CI时想要运行的命令或脚本
可以定义job之间的依赖和缓存
可以执行程序部署并定义部署位置
可以定义想要包含的其他配置文件和模版

二、一个简单的.gitlab-ci.yml 文件示例


# 每个pipeline中包含的stage
stages:
  - build
  - test

# 按照顺序，先执行build中build-code-job

# job 名字
build-code-job:
  # 该job所属的stage
  stage: build
  # 执行该job的脚本
  script:
    - echo "test"
    - ruby -v
    - rake


# 接下来执行test中test-code-job1和test-code-job2，且两个job会并行执行
test-code-job1:
  stage: test
  script:
    - echo "test OK"
    - rake test1



test-code-job2:
  stage: test
  script:
    - echo "test OK"
    - rake test1

三、.gitlab-ci.yml 文件中的一些关键字

1.after_script

定义在每个job（包括失败的job）之后运行的命令
如果job超时或者取消了，after_script 命令就不再执行

2.allow_failure

设置allow_failure:true的job，失败时不影响其他job运行，不影响pipeline运行结果，默认值为false

allow_failure:exit_codes 可以根据exit_codes判断是否允许job失败，例：

test-code-job1:
  stage: test
  script:
    - echo "test OK"
    - exit1 1
  allow_failure:
    exit_codes: 
    - 137

3.artifacts

默认job运行成功后，附加在job的文件或文件夹
可以在.gitlab-ci.yml 中通过设置 artifacts:when，指定job在什么状态下会上传 artifacts

job:
  artifacts:
    when: on_failure

artifacts 文件大小最大支持1G，默认100M，job 结束运行后，可在GitLab job 页面下载对应的 artifacts 文件

默认情况下，最近一个 stages 里的 job 会自动下载上一个 stages 中的 artifacts，可以通过 dependencies / needs 关键字控制

paths 关键字可以指定要把哪个文件放在 artifacts 中

expire_in 关键字可以指定 artifacts 文件保存时间，默认一个月

4.dependencies

可以指定从哪个 job 中下载 artifacts，如果不想下载任何 artifacts 文件，可以给 dependencies 定义一个空的数组


# 该job运行结束后，会生成一个artifacts文件，包含binaries文件夹下的所有文件
build:osx:
  stage: build
  script: make build:osx
  artifacts:
    paths:
      - binaries/

# 该job运行结束后，会生成一个artifacts文件，包含binaries文件夹下的所有文件
build:osx:
  stage: build
  script: make build:osx
  artifacts:
    paths:
      - binaries/

build:linux:
  stage: build
  script: make build:linux
  artifacts:
      paths:
    - binaries/

# 该job运行时，会自动下载build:osx的artifacts
build:osx:
  stage: test
  script: make test:osx
  dependencies:
    - build:osx


# 该job运行时，会自动下载build:linux的artifacts
test:linux:
  stage: test
  script: make test:osx
  dependencies:
    - build:linux

# 该job运行时，会自动下载以上所有job中的artifacts
deploy:
  stage: deploy
  script: make deploy

如果job A 中，dependencies 指定的 job B 由于某种原因没有成功上传 artifacts 文件，job A 就会运行失败（因为 job A 需要的文件找不到了）

5. artifacts:exclude

指定哪些文件不想包含在 artifacts 中

6.artifacts:expire_in

设置 artifacts 保存时间（默认以秒为单位），默认30天

expire_in 可设置的参数示例

‘42’
42 seconds
3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days
never

7.artifacts:name

定义artifacts文件名，可接受预定义变量，如“$CI_JOB_NAME”

8.artifacts:paths

指定 artifacts 中包含的文件，paths 指定路径下的文件都会包含在 artifacts 中

# binaries路径下的文件和.config放入artifacts
  artifacts:
    paths:
      - binaries/
      - .config

paths 参数支持通配符

# 获取xyz结尾的目录下的所有文件
artifacts:
  paths:
    - path/*xyz/*

使用 only: tags 可以设置仅为打了 tag 的 pipeline 生成 artifacts 文件

artifacts:
  paths:
    - path/*xyz/*
  only:
    - tags

9.artifacts:public

指定游客和匿名用户是否可以获取开放 pipeline 的 artifacts 文件，默认值为 true

10.artifacts:reports

可以收集 pipeline job 相关的报告：测试报告、代码质量报告、安全检测报告，这些报告会展示在GitLab 合并请求、pipeline、安全仪表板(security dashboards)模块

11.artifacts:untracked

untracked 为true时，可以将 .gitignore 中被忽略的文件打包进 artifacts 中(如果在.gitlab-ci.yml 中已设置生成 artifacts )，为 false 时，忽略 .gitignore 中被忽略的文件

12.artifacts:when

指定 job 在什么状态下上传 artifacts 文件
可设定值：

on_success：默认值，仅当 job 成功时上传 artifacts
on_failure：仅当 job 失败时上传 artifacts
always：无论 job 什么状态，都会上传 artifacts

13. retry

指定 job 失败时重试次数，最大重试次数：2

when 可以指定出现哪些失败时要重试



参数	描述
always	默认值，job 无论什么原因失败都要重试
unknown_failure	job 失败原因未知时，重试
script_failure	script 运行错误导致 job 失败时重试
api_failure	api错误导致job失败时重试
stuck_or_timeout_failure	当job因为某些原因卡住或超时失败时重试
runner_system_failure	runner 系统错误导致 job 失败时重试
missing_dependency_failure	找不到依赖导致 job 运行失败时重试
runner_unsupported	runner 不支持导致 job 失败时重试
stale_schedule	被延迟的 job 不能运行时重试
job_execution_timeout	script 执行超时导致 job 运行失败时重试
archived_failur	e job 被归档不能运行时重试
unmet_prerequisites	job 未完成前置任务导致运行失败时重试
scheduler_failure	job 未完成前置任务导致运行失败时重试
data_integrity_failure	检测到数据不完整时重试

test:
  script: rspec
  retry:
    max: 2
    when:
      - runner_system_failure

三、gilab的CICD预定义变量

预定义变量, 就是gitlab的CI/CD内置的一些变量

test_variable:
  stage: test
  script:
    - echo "$CI_JOB_STAGE"




变量名称	GitLab	GitLab	Runner 描述
CI	all		0.4
CI_BUILDS_DIR	all	11.10	构建时的最顶层目录
CI_COMMIT_AUTHOR	13.11	all	提交的作者，格式为：名称<邮箱>
CI_COMMIT_BEFORE_SHA	11.2	all	当前分支的上一个提交哈希值
CI_COMMIT_BRANCH	12.6	0.5	提交的分支名，在合并流水线和tag流水线时不可见
CI_COMMIT_DESCRIPTION	10.8	all	提交的描述
CI_COMMIT_MESSAGE	10.8	all	完整的提交信息
CI_COMMIT_REF_NAME	9.0	all	项目的分支名或tag名
CI_COMMIT_REF_PROTECTED	11.11	all	如果作业正在构建的是被保护的分支或tag-拿我格子衫来，值为true
CI_COMMIT_REF_SLUG	9.0	all	CI_COMMIT_REF_NAME的小写形式。
CI_COMMIT_SHA	9.0	all	提交的完整哈希值
CI_COMMIT_SHORT_SHA	11.7	all	8个字符的提交哈希值
CI_COMMIT_TAG	9.0	0.5	提交的tag，仅在tag流水线可见
CI_COMMIT_TIMESTAMP	13.4	all	提交时的时间戳
CI_COMMIT_TITLE	10.8	all	提交的标题
CI_DEFAULT_BRANCH	12.4	all	项目的默认分支
CI_DEPLOY_FREEZE	13.2	all	当流水运行是处于部署冻结阶段时可见，值为true。
CI_ENVIRONMENT_NAME	8.15	all	当前作业的部署环境名，当设置了environment:name 时可见
CI_ENVIRONMENT_URL	9.3	all	当前作业的部署环境地址，只有设置了environment:url可见
CI_JOB_ID	9.0	all	当前作业的ID，系统内唯一
CI_JOB_IMAGE	12.9	12.9	当前作业使用的Docker镜像名
CI_JOB_NAME	9.0	0.5	当前作业名称
CI_JOB_STAGE	9.0	0.5	当前作业所属的阶段名拿我格子衫来
CI_PIPELINE_ID	8.10	all	当前流水线ID（实例级），系统内唯一
CI_PIPELINE_SOURCE	10.0	all	流水线触发方式，枚举值为push,web, schedule, api, external, chat, webide,merge_request_event, external_pull_request_event, parent_pipeline, trigger, 或者 pipeline
CI_PIPELINE_TRIGGERED	all	all	当作业是使用trigger触发的时为true
CI_PIPELINE_URL	11.1	0.5	流水线详情的地址
CI_PIPELINE_CREATED_AT	13.10	all	流水线创建时间
CI_PROJECT_DIR	all	all	存放克隆项目的完整路径，作业运行的目录。
CI_PROJECT_NAME	8.10	0.5	当前项目名称，不包含组名
CI_PROJECT_NAMESPACE	8.10	0.5	项目的命名空间（组名或用户名）
CI_PROJECT_PATH	8.10	0.5	包含项目名称的命名空间
CI_PROJECT_TITLE	12.4	all	项目名称（网页上显示的）
CI_PROJECT_URL	8.10	0.5	项目HTTP(S)地址
CI_RUNNER_TAGS	8.10	0.5	逗号分割的runner标签列表
GITLAB_USER_EMAIL	8.12	all	开始当前作业的用户邮箱
GITLAB_USER_LOGIN	10.0	all	开始当前作业的登录用户名-拿我格子衫来
GITLAB_USER_NAME	10.0	all	开始当前作业的用户名
CI_MERGE_REQUEST_APPROVED （仅合并流水线）	14.1	all	当合并流水线的MR被通过时值为true
CI_MERGE_REQUEST_ASSIGNEES （仅合并流水线）	11.9	all	逗号分割的合并请求指派人列表
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME（仅合并流水线）	11.6	all	合并请求中的源分支名称
CI_MERGE_REQUEST_TARGET_BRANCH_NAME（仅合并流水线）	11.6	all	合并请求中的目标分支名称
CI_MERGE_REQUEST_TITLE（仅合并流水线）	11.9	all	合并请求的标题

四、gilab自定义变量

对于一个项目而言：
可以在 .gitlab-ci.yml 中定义变量
可以在项目上定义
通过api来传递
对在一个组内的所有的项目而言，通过组设置来定义
对于一个GitLab实例下的所有项目而言，通过实例的设置来定义
你可以手动覆盖某个流水线的变量值，或者在手动管道中预先填充它们。

有两种类型的变量:文件或变量。
变量名受到运行程序用于执行脚本的shell的限制。每个shell都有自己的一组保留变量名；确保每个变量都是为你想要使用它的范围定义的。
默认情况下，来自分支项目的管道不能访问父项目中的CI/CD变量。如果你在父项目中为一个来自fork的合并请求运行一个合并请求管道，那么所有的变量对该管道都是可用的。

.gitlab-ci.yml中定义变量

variables:
  TEST_VAR: "All jobs can use this variable's value"

job1:
  variables:
    TEST_VAR_JOB: "Only job1 can use this variable's value"
  script:
    - echo "$TEST_VAR" and "$TEST_VAR_JOB"```

# 参考
- [GitLab CI/CD：.gitlab-ci.yml 文件 (持续更新)](https://www.cnblogs.com/bluefrost/p/14686587.html#:~:text=artifacts%201%20%E9%BB%98%E8%AE%A4job%E8%BF%90%E8%A1%8C%E6%88%90%E5%8A%9F%E5%90%8E%EF%BC%8C%E9%99%84%E5%8A%A0%E5%9C%A8job%E7%9A%84%E6%96%87%E4%BB%B6%E6%88%96%E6%96%87%E4%BB%B6%E5%A4%B9%202%20%E5%8F%AF%E4%BB%A5%E5%9C%A8.gitlab-ci.yml%20%E4%B8%AD%E9%80%9A%E8%BF%87%E8%AE%BE%E7%BD%AE%20artifacts:when%EF%BC%8C%E6%8C%87%E5%AE%9Ajob%E5%9C%A8%E4%BB%80%E4%B9%88%E7%8A%B6%E6%80%81%E4%B8%8B%E4%BC%9A%E4%B8%8A%E4%BC%A0%20artifacts,%E5%85%B3%E9%94%AE%E5%AD%97%E5%8F%AF%E4%BB%A5%E6%8C%87%E5%AE%9A%E8%A6%81%E6%8A%8A%E5%93%AA%E4%B8%AA%E6%96%87%E4%BB%B6%E6%94%BE%E5%9C%A8%20artifacts%20%E4%B8%AD%206%20expire_in%20%E5%85%B3%E9%94%AE%E5%AD%97%E5%8F%AF%E4%BB%A5%E6%8C%87%E5%AE%9A%20artifacts%20%E6%96%87%E4%BB%B6%E4%BF%9D%E5%AD%98%E6%97%B6%E9%97%B4%EF%BC%8C%E9%BB%98%E8%AE%A4%E4%B8%80%E4%B8%AA%E6%9C%88)
- [https://www.cnblogs.com/xingxia/p/gitlab_variables.html](https://www.cnblogs.com/xingxia/p/gitlab_variables.html)