工作准则
1、将代码托管在git
2、在项目根目录创建ci文件.gitlan-ci.yml 在文件中指定构建，测试和部署脚本
3、gitlab将检测到他并使用名为git Runner的工具运行脚本
4、脚本被分组为作业，他们共同组成了一个管道
gitlab-ci的脚本执行需要定制，根据对应的gitlab-runner执行。 代码puhs后，webhook检测到代码变化，会触发gitlan-cl，分配给每个Runner运行对应的script脚本
gitlab 跑步者
类型
share共享类型，运行整个平台项目（gitlab）的job
group 项目组类型，运行特定组（group）下所有项目的作业
sprcific项目类型，运行指定的项目作业（project）
状态
锁定 锁定状态，无法运行项目作业
Paused 暂停状态，暂时不接受新的作业
管道语法
工作（工作）
在每个项目中，Gitlab CL/CD 管道都使用名为 .gitlab-ci.yml 的 YML 文件进行配置，其中可以定义一个或多个作业（jobs）。 每个作业必须有唯一的名称（不能使用关键字），每个作业独立运行，作业在约束下定义相关操作，每个作业必须包含至少一个脚本。
例子：
job1：
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
这里定义了两个作业，每个作业运行不同的命令，命令可以是shell也可以是脚本
脚本
（运行 shell 或脚本）
例子：
job1:
script:
- uname -a
- bundle exec rspec
注意：有时脚本命令需要用单引号或双引号括起来，例如，包含冒号 (:) 的命令需要用引号引起来，以便包装的 YAML 解析器知道将整个内容解释为字符串，而不是“”键: value "" 是的，使用特殊字符是消息：:,{,},[,],,,&,*,#,?,|,-,,=,!,%,%,@,`` `
before_script
用于定义在每个作业之前运行的命令。 必须是一个数组。已知的 scripy 与脚本中任何已知的脚本连接起来并在单个 shell 中一起执行
before_script的失败会导致整个作业失败，其他作业将不再执行。 作业失败不影响 after_script
after_script
用于定义每个作业（包括失败的作业）之后运行的命令
这必须是一个数组
指定的脚本在新的 shell 中执行，与任何 before_script 或 script 脚本分开
before_script或script执行失败不影响after_script执行
stages
用于定义作业可以使用的阶段，是全局定义
同一阶段的作业并行运行，不同阶段的作业顺序执行
stages:
- build
- test
- codescan
- deploy
.pre&.post
.pre 始终是整个管道的第一个运行阶段，.post 始终是整个管道的最后一个运行阶段。 用户定义的阶段都在两者之间运行。 .pre 和 .post 的顺序不能更改。如果管道仅包含 .pre 或 .post 阶段的作业，则不会创建管道
codescan:
stage: .pre
tags:
- build
only:
- master
script:
- echo "codescan"
阶段
每个作业定义并依赖于全局定义的阶段。它允许作业分为不同的阶段，统一的阶段作业可以并行执行
瓦瓦莱斯
定义变量、管道变量、作业变量。 job变量具有最高优先级
标签
指定跑步者
用于从允许该项目的所有 Runner 列表中选择指定的 Runner。 注册Runner时，可以指定Runner的标签
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello,%$USERNAME%:
osx job:
stage:
- build
tags:
- osx
script:
- echo "Hello, $USER:"
allow_failure（允许失败）
allpw_failure 允许作业失败，默认值为 false，如果启用后作业失败，该作业将在用户界面中显示橙色警告，但是管道的逻辑流程将任务该作业成功/通过，并且不会被阻止。 假设所有其他作业均成功，则更改后的作业的阶段及其管道将显示相同的橙色警告。 但是，托管提交将被标记为“通过”而不发出警告。
windows job:
stage:
- build
tags:
- windows
script:
- echo Hello,%$USERNAME%:
allow_failure: true
当（允许控制作业）
on_success 前面阶段中的所有作业都成功时才执行作业，默认值
on_failure 当前面阶段出现失败时执行
always 总是执行作业
manual 手动执行作业
delayed 延迟执行作业
重试（重试）
配置失败时重试作业的次数
如果也失败并且配置了重试，则作业将再次处理，直到达到retry关键字指定的次数
如果当retry设置为2时，但允许作业第二次（第一次重试）成功，则不再重试，重试值必须为正整数，等于或大于0、小于或等于 2（最多允许重试两次，总共允许重试三次）
重试 - 重试 - 精确匹配错误
默认情况下，作业在失败时重试，amx：最大重试次数，当：失败时重试的错误类型
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 ：检测到结构完整性问题。
例子：
unittest:
stage: test
tags:
- build
only:
- master
script:
- ech "run test"
retry:
max: 2
when:
- script_failure
超时——超时
作业级别超时可以超过项目级别超时，但不能超过特定于运行程序的超时
build:
script: build.sh
timeout: 3hours 30minutes
test:
script: rspec
timeout: 3h 30m
超时-超时-跑步者超时
如果小于项目定义的超时将优先，该功能可用于通过设置较大的超时（例如一周）来防止 Shared Runner 被项目占用。在未配置时，Runner 不会覆盖项目超时
示例1：运行程序超时大于项目超时
运行程序超时设置为 24 小时，项目的 CI/CD 超时设置为 2 小时。
作业将在 2 小时后超时
示例 2：未配置运行程序超时
运行器没有设置超时时间，项目的CI/CD超时设置为2小时
作业将在 2 小时后超时
示例 3：运行程序超时小于项目超时
运行器超时设置为30个分支，项目的CI/CD超时设置为2小时
作业 30 分钟后超时
并行 - 并行作业
配置并行运行的作业实例数量，该值必须大于等于2且小于等于50
这将创建并行运行的同一作业的 n 个实例，按顺序命名，从 job_name 1/n 到 job_name n/n
仅&例外限制分支标签
仅且例外地使用分支策略来限制岗位建设
只有定义这些分支和标签的git项目才会被作业执行
ecxept定义了git项目的那些分支和标签不会被作业执行
job:
#use regexp
only:
- /^issue-.*$/
#use specli keyword
ecxept:
- branches
规则——构建规则
规则允许单个规则的顺序小程序直到匹配为止，并为作业动态提供属性
规则不能与 only/ except 组合
可用规则
if （如果条件匹配）
changes （指定文件发生变化）
exists （指定文件存在）
列：规则-如果-条件-匹配
如果DOMAIN的值匹配，则需要手动运行
与 on_success 不匹配
从上到下判断条件，匹配就会停止
多条件匹配可以使用&&||
variables:
DOMAIN: example.com
codescan:
stage: codescan
tags:
- build
script:
- echo "codescan"
- sellp 5;
#parallel:5
rules:
- if:'$DOMAIN == "example.com"'
when: manual
when: on_success
规则更改 - 文件更改
接受文件路径数组
true 如果提交 jenkinsfile 发送的更改
codescan:
stage: codescan
tags:
- build
script:
- echo "codescan"
- sleep 5;
#parallel：5
rules:
- changes:
- jenkinsfile
when: manual
- if:'$DOMAIN == "example.com"'
when: on_success
- when: on_success
规则-allow_failure - 允许失败
使用规则-allow_failure: true
规则：允许作业失败或手动作业等待操作而不停止管道本身
job:
script "echo Hello,Rules"
rules:
- if:'$CI_meRGE_REQUEST_TARGET_BRABCH_NAME == "master"'
when: manual
allow_failure
工作流程规则 - 管道创建
定价工作流关键字适用于整个管道，并将决定是否创建管道
when：三个字可以是always或never，如果不提供则默认值always
variables:
DOMAIN: example.com
workflow:
rules:
- if: '$DOMAIN == "example.com"'
- when: always
缓存 - 缓存
存储编译项目所需的运行时依赖，并指定项目工作区中作业之间需要缓存的文件目录
全局缓存是在作业外部定义的，对所有作业生效。 作业时钟缓存优先于全局
缓存：路径
在作业构建中定义缓存，目标目录中的所有jar文件都会被缓存
缓存是全局定义的：路径会被作业覆盖，以下示例将缓存目标
build:
script: test
cache:
paths:
- target/*.jar
cache:
paths:
- my/files
build:
script: echo "Hello"
cache:
key: build
paths:
- target/
由于缓存是在作业之间共享的，如果不同的作业使用不同的路径，就会出现缓存覆盖的问题
如何让不同的作业缓存不同的缓存？
设置不同的cache:key
缓存：key - 缓存标签
为缓存做一个标记，可以配置job和branch为关键，实现branch和job特定的缓存
当为不同的作业定义不同的cache:key时，每个作业都会分配一个独立的缓存
cache：关键变量可以使用任何预定义的变量模板库，默认为default
从 gitlab9.0 开始，默认情况下一切都在管道和作业之间共享
按分支设置缓存
cache:
key: ${CI_COMMIT_REF_SLUG}
cache:key:files-文件变化自动创建缓存
files：文件发送和更改时自动重新生成缓存（files指定最多两个文件），提交时检查指定文件
生成一个key根据指定文件计算sha校验和，如果文件没有改变则该值为默认值
cache:
key:
files:
- Gemfile.lock
- package.json
paths:
- endor/ruby
- node_modules
cache:key:prefix- 组合生成 sha 校验和
prefix：允许给定前缀的值与指定文件生成的密钥组合
全局缓存在这里定义。 如果文件传输发生变化，则该值为repec-xxx11122211。 如果没有改变的话就是rspec-default
cache:
key:
files:
- Gemfile.lock
prefix: $(CI_JOB_NAME)
path:
- vendor/ruby
rspec:
script:
- bundle exec rspec
缓存：策略 - 缓存策略
默认情况下，文件在执行开始时下载，结束时重新上传
策略：pull 跳过下载步骤，策略：push 跳过上传步骤
文物 - 文物
用于指定作业成功或失败时应附加到作业的文件或目录列表。 作业完成后，工件将发送到gitlab，并可以在gitlab ui中下载
artifacts:
paths:
- target/
例子：
default-job:
script:
- mvn test -U
except:
- tags
release-job:
script:
- mvn package -U
artifacts:
path:
- target/*.war
oniy:
- tags
工件：expose_as-MR 显示工件
关键字 hide_as 可用于在合并请求 UI 中公开作业工件
每个合并请求最多可以公开 10 个作业工件
列表：
test:
script:
- echo 1
aritifacts:
expose_as:'artifact 1'
patchs:
- path/to/file.txt
工件：名称 - 工件名称
通过name命令定义创建的射箭存档的名称，可以为每个存档使用唯一的名称
artifacts:name 默认名称为artifacts模板库，下载artifacts后改为artifacts.zip
列表：
job:
artifacts:
name: "$CI_JOB_NAME"
patchs:
- binaries/
job:
artifacts:
name: "$CI_COMMIT_REF_NAME"
paths:
- binaries/
artifacts:when - 工件创建条件
用于上传作业失败或成功时的工件
on_success 如果作业成功则仅上传工件 默认
on_failure 仅在作业失败时上传工件
无论工作状态如何，始终上传工件
例子：
job1:
artifacts:
when: on_failure
job2:
artifacts:
when: on_success
job3:
artifacts:
when: always
工件：expire_in - 工件保留时间
产品的有效期从上传并存储到gitlab时开始计算。 如果没有定义过期时间，则默认为30天
expire_in 的值是以秒为单位的警告时间，除非提供单位
例子：
job:
artifacts:
expire_in: 1 week
工件：报告：junit - 单元测试报告
收集junit单元测试报告，最喜欢的JUnit报告将作为工作上传到gitlab并自动显示在合并请求中
列表：
build:
stage: build
tags:
- build
only:
- master
script:
- mvn test
- mvn cobertura:cobertura
- ls target
artifacts:
name: "$CI_JOB_NAME-$CI_COMMIT"_REF_NAME"
when: on_success
expose_api: 'artifact 1'
paths:
- target/*,jar
reports
junit: target/surefire-reports/TEST-*.xml
依赖项获取工件
定义从中获取工件的作业列表。 只能从当前阶段之前执行的阶段定义作业。 定义空数组将跳过下载此作业的任何工件。 不会考虑之前作业的状态，因此如果失败或未运行手动作业，则不会发生错误。 如果未设置依赖关系的工作工件已过期或被删除，则依赖作业将失败。
列表：
unittest:
dependencies:
- build
需求阶段并行性
作业可以无序执行，而不是按阶段顺序运行某些作业，而是可以同时运行多个阶段。
如果将needs:设置为指向因only/ except规则而未实例化的作业，或者不存在，则创建管道时会出现YML错误
列表：
module-a-test:
stage: test
script:
- echo "Hello"
- sleep 10
needs:
- job: "module-a-build"
需求-产品下载
使用需求时，可以使用artifacts: true或者artifacts: false来控制artifacts的下载，默认为true
列表：
module-a-test:
stage: test
script:
- echo "Hello"
- sleep 10
needs:
- job: "module-a-build"
artifacts: true
include:local - 引入本地配置
可以允许导入外部 YAML 文件，文件扩展名为 .yml 或 yaml
可以使用合并功能自定义和覆盖包含本地定义的 CI/CD 配置
从同一存储库导入文件，使用相对于根目录的完整路径引用，与配置文件位于同一分支上
列表：
ci/localci.yml
stages:
- deploy
deployjob:
stage: deploy
script:
- echo 'deploy'
include:
local: 'ci/localci.yml'
include:file - 导入其他项目配置
引入另一个项目的master分支的.gitlab-ci.yml配置
include:
- project:
ref: master
file: '.gitlab-ci.yml'
include-template-引入官方配置
include:
- template: AUTO-DevOps.gitlab-ci.yml
include:remote - 引入远程配置
