.gitlab-ci.yml关键词完整解析（二）

小咪咪 2022-12-27 12:48 43阅读 0赞

### .gitlab-ci.yml关键词完整解析（二） ###

上次我们介绍了  
`script`, `image`, `artifacts` ,`tags`, `cache` ,`stage` ,`when` ,`only/except`。  
学习了这几个关键词的用法，就不难配置一条简单的流水线。但如果要遇到更加复杂的业务场景，如微服务，流水线继承，多流水线,等复杂场景，那么只靠以上的几个用法是无法实现的。下面我就再给大家讲解其他几个更加复杂的关键词。  
这次讲解的关键词有  
`before_script`, `after_script`, `dependencies`, `environment`, `extends`, `include`, `interruptible` ,`parallel`, `rules` ,`trigger`, `services`

#### [before\_script][before_script] ####

before\_script 关键词是用于在每个任务之前执行的脚本，但是会在artifacts恢复之后执行。你可以这样定义一个全局的before\_script，

default:
      before_script:
        - echo "Execute this script in all jobs that don't already have a before_script section."

也可以在一个任务中中单独定义

job:
      before_script:
        - echo "Execute this script instead of the global before_script."
      script:
        - echo "This script executes after the job's `before_script`"

任务中的`before_script`会覆盖全局的`before_script`

#### [after\_script][after_script] ####

after\_script与before\_script类似，用于定义多行脚本，会在任务执行完成后执行，即使任务失败也会被执行。如果任务被取消或者超时，after\_script就不会被执行了，目前官方正在计划这个特性。  
可以定义全局的，也可以定义局部的

default:
      after_script:
        - echo "Execute this script in all jobs that don't already have an after_script section."
    
    job1:
      script:
        - echo "This script executes first. When it completes, the global after_script executes."
    
    job:
      script:
        - echo "This script executes first. When it completes, the job's `after_script` executes."
      after_script:
        - echo "Execute this script instead of the global after_script."

#### [dependencies][] ####

dependencies关键词是定义特定的job运行规则。默认artifacts是从当前阶段产生，在后续的阶段都会被下载，但我们可以使用dependencies关键词来控制artifacts从哪里下载，  
这里有一个例子，

build:osx:
      stage: build
      script: make build:osx
      artifacts:
        paths:
          - binaries/
    
    build:linux:
      stage: build
      script: make build:linux
      artifacts:
        paths:
          - binaries/
    
    test:osx:
      stage: test
      script: make test:osx
      dependencies:
        - build:osx
    
    test:linux:
      stage: test
      script: make test:linux
      dependencies:
        - build:linux
    
    deploy:
      stage: deploy
      script: make deploy

根据这个例子我们不难看出，  
任务test:osx 依赖build:osx  
任务test:linux 依赖 build:linux  
这样配置以后 任务test:linux 就不用等任务build:osx 执行完成在执行了，只需要等待任务build:linux完成  
很好地利用了依赖关系来优化流水线的速率，前四个任务都执行完成后，才会执行最后一个部署的任务。

#### [environment][] ####

environment是用于定义环境变量，可以是用k-v的方式定义  
如

deploy to production:
      stage: deploy
      script: git push production HEAD:master
      environment:
        name: production

需要注意的是这里定义的环境变量是不能在script值使用的。  
这个关键词可以和review和merge搭配。

#### [extends][] ####

这个关键词可以使一个任务继承另一个任务。  
如下案例

.tests:
      script: rake test
      stage: test
      only:
        refs:
          - branches
    
    rspec:
      extends: .tests
      script: rake rspec
      only:
        variables:
          - $RSPEC

任务rspec 继承了.tests任务，在流水线中.tests是一个隐藏的任务，在流水线中，以英文远点开头的任务名，都是隐藏的任务。不会被执行。 被rspec继承后，相同的key会以rspec为准，rspec没有的，而.tests有的，则合并到rspec中，  
合并后的结果是

rspec:
      script: rake rspec
      stage: test
      only:
        refs:
          - branches
        variables:
          - $RSPEC

使用这一个手段，可以写一个模板，只要稍微改改就能后使用。非常适合大批量编写流水线。

#### [include][] ####

使用include可以导入一个或多个额外的yaml文件到你的CICD配置里，这一你就可以将一个很长的流水线，分隔出来。使用include来引入。  
也可以将几个流水线中相同的配置，提取出来，公用。引入的文件扩展名 必须是.yaml或者.yml两种，其他的不行。  
include 关键词下，有四个可选性，  
local, 引入一个当前项目的文件  
file, 引入一个不同项目的文件  
remote, 引入一个公网文件，  
template, 引入一个由GitLab提供的模板

下面是几个例子

include:
      - local: '/templates/.gitlab-ci-template.yml'

include:
      - project: 'my-group/my-project'
        file: '/templates/.gitlab-ci-template.yml'

include:
      - local: '/templates/.gitlab-ci-template.yml'

include:
      - project: 'my-group/my-project'
        ref: master
        file: '/templates/.gitlab-ci-template.yml'
    
      - project: 'my-group/my-project'
        ref: v1.0.0
        file: '/templates/.gitlab-ci-template.yml'
    
      - project: 'my-group/my-project'
        ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
        file: '/templates/.gitlab-ci-template.yml'

include:
      - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'

#### [trigger][] ####

trigger 是应对那些更加复杂的CICD流程，如多流水线，父子流水线  
使用它可以定义一个下游的流水线，配置了trigger的任务是不能跑脚本的，就是说不能定义script, before\_script, 和 after\_script.  
项目这个是一个多项目流水线

rspec:
      stage: test
      script: bundle exec rspec
    
    staging:
      stage: deploy
      trigger: my/deployment

流水线执行完test任务后就会去执行`my/deployment`项目的流水线

配置下游流水线式也可以执行分支

rspec:
      stage: test
      script: bundle exec rspec
    
    staging:
      stage: deploy
      trigger:
        project: my/deployment
        branch: stablez

#### [rules][] ####

rules是用于规定任务的执行规则，使用一个表达式，来规范那些任务执行，那些任务不执行.还可以在任务成功，或者失败后，触发另一个任务。  
如下面这个例子

docker build:
      script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
      rules:
        - if: '$CI_COMMIT_BRANCH == "master"'
          when: delayed
          start_in: '3 hours'
          allow_failure: true

如果当前的分支是master分支则任务执行就延迟3个小时，并且允许失败。  
rules的下面有是哪个可选属性

*  if 使用if表达式 添加或移除一个任务， 类似 only:variables.
 *  changes 根据某些个文件是否改变来追加或移除一些任务。类似 only:changes.
 *  exists 根据是否存在特定文件来追加或移除一些任务

if中可以使用CICD的所有预设变量，分支，来源，合并请求，commit，push web，schedule等。可以针对不用的情景配置不用的规则。  
在看下这个例子

job:
      script: echo "Hello, Rules!"
      rules:
        - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
          when: manual
          allow_failure: true

解释起来并不复杂，一个判断语句，二句赋值语句。即如果当前分支是master，在任务的执行方式改为手动，并且运行失败。

#### 写在最后 ####

懂了以上这些关键词，那就不难写出一条规则复杂，易于扩展的流水线。  
遇到流水线问题，可以私聊我。

关注我，后续还有更多优质精讲文章。  
首发地址 https://www.ebaina.com/articles/140000005088

[before_script]: https://docs.gitlab.com/ee/ci/yaml/README.html#before_script
[after_script]: https://docs.gitlab.com/ee/ci/yaml/README.html#after_script
[dependencies]: https://docs.gitlab.com/ee/ci/yaml/README.html#dependencies
[environment]: https://docs.gitlab.com/ee/ci/yaml/README.html#environment
[extends]: https://docs.gitlab.com/ee/ci/yaml/README.html#extends
[include]: https://docs.gitlab.com/ee/ci/yaml/README.html#include
[trigger]: https://docs.gitlab.com/ee/ci/yaml/README.html#trigger
[rules]: https://docs.gitlab.com/ee/ci/yaml/README.html#rules