gitlab--基础--5.3--CICD--gitlab-ci.yml关键字

gitlab–基础–5.3–CICD–gitlab-ci.yml关键字

---

1、before_script和after_script

1. 可以在job中 定义 before_script，after_script
2. 可以将其定义为顶级元素，定义为顶级元素将为每一个job都执行相应阶段的脚本或命令。

1.1、before_script

1. 用于定义在所有作业之前需要执行的命令，比如更新代码、安装依赖、打印调试信息之类的事情。
2. job类型 会覆盖掉 global类型 的值

1.2、after_script

1. 用于定义在所有作业(即使失败)之后需要执行的命令，比如清空工作空间。
2. job类型 会覆盖掉 global类型 的值

1.3、案例1

before_script:
  - echo "before_script"
after_script:
  - echo "after_script"

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test

1.4、案例2

 
before_script:
  # 会复写全局设置
  - echo "before_script"
after_script:
  - echo "after_script"

stages:
  - test
# test
test:
  stage: test
  # 会复写上面的before_script
  before_script:
    - echo before_script test 
  script:
    - echo test

2、stages和stage

2.1、stages

1. 定义流水线全局可使用的阶段
2. 阶段元素的排序定义了作业执行的顺序
3. 相同 stage 的job并行运行
4. 默认情况：上一阶段的作业全部运行成功后才执行下一阶段的作业。
5. 默认有三个阶段， build 、test 、deploy 三个阶段，即 构建 、测试 、部署 。
6. 如果一个作业未定义 stage 阶段，则作业使用 test 测试阶段。
7. 默认情况下，任何一个前置的作业失败了，commit提交会标记为failed并且下一个stages的作业都不会执行。

2.1.1、案例

stages:
  - build
  - test
  - deploy

运行顺序

1. 运行所有的 build 。
2. 如果所有作业都 build 运行成功，那么开始运行所有的 test。
3. 如果所有作业都 test 运行成功，那么开始运行所有的 deploy。
4. 如果所有作业都 deploy 成功，则标记 job 为 passed 。
5. 如果在之前动作中有任何失败，则标记 job 为 failed 并终止 job 执行。
6. 没有定义时的默认动作:
   1. 如果 .gitlab-ci.yml 文件中没有定义 stages，stages 将会被设置成 build -> test -> deploy
   2. 如果 job 没有定义 stage, 则 job 的 stage 将会被设置成 test

2.2、stage

1. 定义当前 job 运行的阶段名称
2. 相同阶段名称的 job 将会并行执行。
3. 默认: test

2.2.1、案例

   
stages:
  - build
  - test
  - deploy

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

3、tags

1. 在注册Runner的过程中，我们可以设置Runner的标签
2. tags可通过 标签名称 来 获取对应标签名称的Runners来运行jobs

3.1、案例

#单元测试
unit-test:
  # 属于哪个阶段
  stage: verify
  #  获取对应标签名称的Runners来运行jobs
  tags:
    # 标签名称
    - test-cicd 
  # 执行脚本
  script:
    - echo unit-test 

4、script

1. 是作业中唯一必须的关键字参数
2. 是运行器需要执行的脚本
3. 可以执行多个shell脚本
4. script命令包含以下特殊字符，需要使用单引号或者是双引号包裹起来

4.1、script命令包含以下特殊字符，需要使用单引号或者是双引号包裹起来

:,{,},[,],&,*,#,?,|,-,<,>,=,!

原因：举个例子，当命令中包含冒号(:)时，script需要被包在双引号中，这样YAML解析器才可以正确解析为一个字符串而不是一个键值对(key:value)

4.2、案例

 
job:
	# 通过空格 执行多个命令
    script: mvn clean test

或者

job:
    script:
        - mvn
        - clean test

表job作业需要执行的命令是"mvn clean test"。

5、only 和 except

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

5.2、两个参数的几条用法规则

1. only和except如果都存在在一个job声明中，则同时 only、except 进行过滤(注意，不是忽略 except 条件)

2. only和except允许使用正则

3. only和except 允许指定用于过滤forks作业的存储库路径

4. only和except允许使用特殊的关键字
   

5. only 和 except 支持高级策略，以下四个关键字可以使用

   1. refs
   2. variables
   3. changes
   4. kubernetes

5.3、示例1

1. job只会在 feature-开头的分支执行
2. 其他所有分支被跳过

job:
    # 使用正则
    only:
        - /^feature-.*$/
    # use special keyword
    except:
        - branches

5.3、示例2

1. job 会在打了tag的分支上 运行
2. job 会在api所触发上 运行
3. job 会在每日构建任务上 运行

job:
    # 使用特殊的关键字
    only:
        - tags      # tag 分支 commit 之后触发
        - triggers  # API 触发
        - schedules # 每日构建触发

5.3、示例3

job将会在父仓库gitlab-org/gitlab-ce的非master分支有提交时运行。

job:
    only:
        - branches@gitlab-org/gitlab-ce
    except:
        - master@gitlab-org/gitlab-ce

6、when

1. on_success(默认)：只有前面stages的所有工作成功时才执行
2. on_failure：当前面stages中任意一个jobs失败后执行
3. always：无论前面stages中jobs状态如何都执行
4. manual：
   1. 手动执行作业，作业不会自动执行，需要人工手动点击启动作业。(GitLab8.10增加)
   2. 在GitLab的用户界面中显示该作业的"播放"按钮，意味着仅在单击"播放"按钮时才会触发job。
5. delayed:
   1. 延迟执行作业，配合start_in关键字一起作用
   2. start_in 设置的值必须小于或等于1小时
   3. start_in 设置的值示例： 10 seconds 、 30 minutes 、 1 hour ，前面的作业结束时计时器马上开始计时。

6.1、案例

# 定义流水线的各个阶段
stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanup

before_script:
  - echo "before_script"
after_script:
  - echo "after_script"

#单元测试
unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo "unit-test"

#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo "java-package"

#push镜像
docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo "docker-push"


# 当前面stages中任意一个jobs失败后执行
docker-push2:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo "docker-push2"
  when: on_failure
    
# 手动执行(GitLab8.10增加)
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo "service-1"
  when: manual 

# 前面的job成功与否，都会执行该job
cleanup_job:
  stage: cleanup
  script:
    - echo clean up
  when: always 

7、allow_failure

1. 跟when一起控制job执行与否的配置
2. 当你希望一个 job 执行失败之后，CI 仍要继续执行时，可以设置这个值为 true
3. 如果你设置了 allow_failure=true， 并且 job 执行失败，这时候 CI 会显示执行成功但是会出现一个警告信息。警告信息用来提示有一个允许失败的任务执行失败

7.1、案例

下面的这个例子中，java-package和java-package2将会并列进行，如果java-package2失败了，它也不会影响进行中的下一个stage，因为这里有设置了allow_failure: true。

stages:
  - verify
  - build
  - dockerpush
  - deploy
  - cleanup

before_script:
  - pwd
after_script:
  - echo after_script

#单元测试
unit-test:
  stage: verify
  tags:
    - test-cicd
  script:
    - echo unit-test

#java编译
java-package:
  stage: build
  tags:
    - test-cicd
  script:
    - echo build

#java编译
java-package2:
  stage: build
  tags:
    - test-cicd
  script:
    # 该shell会导致job执行失败
    - execute_script_that_will_fail 
  # 不影响后面的任务进行
  allow_failure: true 

#push镜像
docker-push:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    - echo docker-push

#deploy
service-1:
  stage: deploy
  tags:
    - test-cicd
  script:
    - echo deploy
  when: manual

cleanup_job:
  stage: cleanup
  tags:
    - test-cicd
  script:
    - echo clean up
  when: always

java-package2会执行错误

运行的pipeline如下，可见java-package2的执行错误

8、variables

1. 为.gitlab-ci.yml增加变量
2. 变量将会被设置入任务环境。
3. 通过两种方式引用
   1. 美元符+大括号引用：${}
   2. 美元符：$
4. 整数(以及字符串)对于变量的名称和值都是合法的。浮点数是不合法的，不能使用。
5. 当变量关键字被用于工作层面时，它将覆盖全局YAML变量和同名的预定义变量

8.1、案例

# 定义变量
variables:
  # K,V形式定义变量
  SOFT_VERSION: '1.0'
  TAG_NAME: 'app'
#构建镜像
docker-build:
  stage: dockerpush
  tags:
    - test-cicd
  script:
    # 使用变量
    - docker build -t $TAG_NAME:${SOFT_VERSION}

8.2、在gitlab中定义变量

1. 如果有些值不想在配置文件中显示，比如密码什么的，可以在代码仓库中自定义变量，跟在.gitlab-ci.yml配置变量效果是一样的

9、image and services

这两个关键字允许使用一个自定义的 Docker 镜像和一系列的服务，并且可以用于整个 job 周期。

9.1、image

1. 指定了该阶段使用的基础镜像
2. 该镜像为本地手动提前创建并推送;

9.2、services

1. 指定了该阶段依赖使用的服务
2. 举例：比如mongo和redis，该job运行时会初始化指定服务版本的容器，并分别暴露域名为mongo:27017、redis:6379
3. 需要在配置文件中提前配置好CI专用的配置文件供后续使用。

10、environment

1. environment 用于定义作业部署到特殊的环境中。
2. 如果指定了 environment ，并且在该环境列表中没有该名称下的环境，则会自动创建新环境。

在最简单的格式中，环境关键字可以定义为：

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

在上面这个例子中，deploy_to_production作业将会执行部署操作部署到production环境。

10.1、environment:name

1. 设置环境的名称
2. name可以设置为
   1. letters(字母)
   2. digits(数字)
   3. spaces(空格)
   4. _
   5. /
   6. $
   7. {
   8. }
3. 常用的名称
   1. qa(验证)
   2. staging(模拟环境)
   3. production(生产环境)
   4. development(开发环境)
   5. integration(集成环境)

10.2、environment:url

1. 这是设置一个可选值
2. 它会显示在按钮中，点击它可以带你到设置的URL页面。

10.2.1、案例

如果job都成功完成了，在 部署/环境 页面中将会创建一个请求的按钮，它将指向https://www.baidu.com/

deploy to production:
  stage: deploy
  script: echo '部署到生产'
  environment:
    name: production
    url: https://www.baidu.com/
	

10.3、environment:on_stop and environment:action

1. environment:on_stop 与 environment:action 配合使用。
2. 可以通过 environment:on_stop 关键字定义一个关闭(停止)环境的作业。
3. action 关键字在关闭环境的作业中定义。

10.3.1、案例

review_app:
  stage: deploy
  script: echo "deploy-app"
  environment:
    name: review
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  script: echo "delete-app"
  when: manual
  environment:
    name: review
    action: stop

在上面的示例中，设置 review_app 作业用于部署代码到 review 评审环境中，同时在 on_stop 中指定了 stop_review_app 作业。
一旦 review_app 作业成功执行，它将根据 when 下定义的内容触发 stop_review_app 作业。

运行完成后，在 stop_review_app 作业界面需要手动点击 停止当前环境 才能启动 stop_review_app 作业的执行。

stop_review_app 作业执行完成后，会停止 review 评审环境，在 环境 –> 已停止 列表中可以看到 review 评审环境。

10.3.2、stop_review_app 作业必须配合定义以下关键字

1. when：何时执行删除或停止环境作业
2. environment:name： 环境名称需要与上面的 review_app 作业保持一致，即 review 评审环境
3. environment:action：执行何种动作，stop 停止环境
4. stage ：与 review_app 作业的阶段保持一致，都是 deploy

10.4、environment:auto_stop_in

1. 用于指定环境的生命周期
2. 当过期时，GitLab 会自动停止它们。

10.4.1、案例

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    auto_stop_in: 1 day

当review_app工作被执行，环境的生命期被设置为1天。

10.5、environment:kubernetes

用于配置部署到Kubernetes集群。

10.5.1、案例

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      namespace: production

这将设置部署作业，以便使用生产的Kubernetes命名空间部署到生产环境。

10.6、Dynamic environments

1. 使用变量动态生成 环境名称和url
2. 变量包含
   1. 预定义
   2. 安全变量
   3. gitlab-ci.yml中的变量

10.6.1、案例

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

11、cache

1. cache 缓存机制
2. 作用范围
   1. 全局设置
      1. 所有作业都会使用这个定义
   2. 每个作业中设置。
3. 可以在不同的的流水线或作业之间共享数据。
4. 在 artifacts 工件之前恢复缓存。
5. 用来指定一个文件和目录的列表，这些文件和目录在作业之间被缓存。
6. 仅能使用项目工作空间中的路径作为缓存的路径。

11.1、cache:paths

缓存二进制文件中以.apk结尾的所有文件和.config文件。

rspec:
  script: test
  cache:
    paths:
    - binaries/*.apk
    - .config

11.2、cache:key

1. key指令允许我们定义缓存的作用域(亲和性)
2. 可以是所有jobs的单个缓存
3. 可以是每个job
4. 可以是每个分支或者是任何你认为合适的地方。

举例

要启用每个分支缓存：

cache:
  key: "$CI_COMMIT_REF_SLUG"
  paths:
    - binaries/

11.3、cache:key :files

11.4、cache: key:prefix

12、artifacts

1. 用于指定一个文件和目录的列表，当作业成功、失败或总是成功时，这些文件和目录应该被附加到作业中。
2. 工作完成后，工件将被发送到GitLab，并可在GitLab用户界面上下载。

12.1、artifacts:paths

1. 用于指定哪些文件或文件夹会被打包成工件，仅仅项目工作空间的路径可以使用。

12.1.1、案例

将目录 docker/ 和文件 pom.xml 打包成工件

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    paths:
      - docker/
      - pom.xml

12.1.2、案例

要禁用工件传递，请使用空依赖关系定义作业：

job:
  stage: build
  script: make build
  dependencies: []

12.1.3、案例

可以仅为打标记的release发布版本创建工件，这样可以避免临时构建产生大量的存储需求：

default-job:
  script:
    - mvn test -U
  except:
    - tags

release-job:
  script:
    - mvn package -U
  artifacts:
    paths:
      - target/*.war
  only:
    - tags

上面的示例中，default-job 作业不会在打标记的release发布版本中执行，而 release-job 只会在打标记的release发布版本执行，并且将 target/*.war 打包成工件以供下载。

12.2、artifacts:expose_as

1. 定义展示包的名称

2. expose_as 可用于在合并请求用户界面中公开作业工件。

3. 注意以下事项：

   1. 每个合并请求最多可以公开 10 个作业工件。
   2. 不支持全局模式。
   3. 如果指定了一个目录，如果目录中有多个文件，则链接将指向作业工件浏览器。
   4. 对于具有 .html、.htm、.txt、.json、.xml 和 .log 扩展名的公开单个文件工件，如果 GitLab Pages 是：
      1. 启用后，GitLab 将自动渲染工件。
      2. 未启用，您将在工件浏览器中看到该文件

12.2.1、案例

test:
  script: [ 'echo 1' ]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['path/to/file.txt']

使用此配置，GitLab 会将链接artifact 1 添加到指向 file1.txt 的相关合并请求中。

12.2.2、案例

匹配整个目录：

test:
  script: [ 'echo 1' ]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['path/to/directory/']

12.3、artifacts:name

1. 工件的默认名称是 artifacts ，当下载时名称是 artifacts.zip 。
2. 通过 artifacts:name 关键字可以自定义工件的归档名称
3. 归档名称可以使用预定义的变量。
4. 如果分支名称中包含斜杠(比如 feature/my-feature )，推荐使用 $CI_COMMIT_REF_SLUG 代替 $CI_COMMIT_REF_NAME 作为工件名称。

12.3.1、案例

使用工件名称：

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - docker/
      - pom.xml

12.3.2、案例

使用当前分支或tag版本标签名作为工件名称：

  
stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "$CI_COMMIT_REF_NAME"
    paths:
      - docker/
      - pom.xml

12.3.3、案例

同时使用当前作业名称以及当前分支或tag版本标签名作为工件名称

 

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - docker/
      - pom.xml

12.3.4、案例

同时使用当前作业阶段名称以及当前分支名称作为工件名称

 

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
    paths:
      - docker/
      - pom.xml

12.3.5、案例

如果你使用的 Windows系统的Batch批处理脚本 ，则需要把 $ 替换成 %：

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "%CI_JOB_STAGE%-%CI_COMMIT_REF_NAME%"
    paths:
      - docker/
      - pom.xml

12.3.6、案例

如果你使用的 Windows系统的PowerShell脚本 ，则需要把 $ 替换成 $env:：

stages:
  - test
# test
test:
  stage: test
  script:
    - echo test 
  artifacts:
    name: "$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"
    paths:
      - docker/
      - pom.xml

12.4、artifacts:untracked

1. 用于将git未加入版本库的文件作为工件文件。
2. 将会忽略配置文件 .gitignore。

12.4.1、案例

将所有的未跟踪文件打包成工件

artifacts:
  untracked: true

12.4.2、案例

将所有的未跟踪文件以及目录 binaries 中文件打包成工件：

artifacts:
  untracked: true
  paths:
    - binaries/

12.5、artifacts:when

1. 用于在作业失败时或者忽略失败时上传工件。
2. 可以设置以下值：
   1. on_success：默认值，当作业成功上传工件。
   2. on_failure：当作业失败上传工件。
   3. always：无论作业是否成功一直上传工件。

12.5.1、案例

当作业失败时，上传工件

job:
  artifacts:
    when: on_failure

12.6、artifacts:expire_in

1. 用于设置工件的过期时间。过期后，不能再访问该工件

2. 可以点击界面上的 保存 保持按钮，永久保存工件。

3. 默认情况下每小时检查一次工件是否过期(通过cron作业)

4. 工件默认有效期是30天

5. 默认时间单位：秒

12.6.1、设置 默认的有效时间

12.6.2、时间单位 案例

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

12.6.3、案例

设置工件有效期为一周

job:
  artifacts:
    expire_in: 1 week

12.7、artifacts:reports

1. 用于收集测试报告(report)，并在GitLab UI界面中显示出来。
2. 无论作业是否成功，都会收集测试报告。
3. 可以通过设置工件的打包路径 artifacts:paths 添加测试的报告输出文件。
4. artifacts:reports:junit 可以用来收集单元测试的报告，查看 JUnit test reports 获取更详细的信息和示例。

12.7.1、案例

下面是从Ruby的RSpec测试工具中收集JUnit XML文件的示例：

rspec:
  stage: test
  script:
  - bundle install
  - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

12.7.2、一个作业中指定多个单元测试报告

可以在一个作业中指定多个单元测试报告，GitLab会自动将他们转换成一个文件，可以像下面这样表示报告的路径：

1. 文件匹配模式: junit: rspec-.xml
2. 文件列表: junit: [rspec-1.xml， rspec-2.xml， rspec-3.xml]
3. 混合模式：junit: [rspec.xml， test-results/TEST-.xml]

13、coverage

1. 从作业的输出log中提取代码覆盖率。
2. 仅支持正则表达式方式获取覆盖率。
3. 字符串的前后必须使用’/'包含 来表明一个正确的正则表达式规则。
4. 特殊字符串需要转义。

13.1、案例

job1:
  coverage: '/Code coverage:\d+\.\d+%/'

如果在作业日志中输出了"Code coverage:80.2%"，我们使用上面的正则表达式就可以获取到代码的覆盖率。然后在作业的右上角处就会显示 Coverage:80.2% 。

14、retry

1. 当一个作业发生失败时，何时以及有多少次可以自动重试。
2. 用于配置当作业失败时可以重新执行的次数。
3. 当作业失败时，如果配置了 retry ，那么该作业就会重试，直到允许的最大次数。
4. 如果 retry 设置值为2，如果第一次重试运行成功了，那么就不会进行第二次重试。
5. retry 设置值只能是0、1、2三个整数。
6. retry两个关键字
   1. max : 最大重试次数
   2. when : 何时重试

14.1、when 可以是以下值

1. always : 一直重试，默认值。
2. unknown_failure ：当错误未知时重试。
3. script_failure ： 脚本错误时重试。
4. api_failure ： API调用错误时重试。
5. stuck_or_timeout_failure ： 作业卡住或超时错误时重试。
6. runner_system_failure ： 运行器系统错误(如设置工作失败)时重试。
7. missing_dependency_failure ： 依赖工件丢失错误时重试。
8. runner_unsupported ： 运行器不支持错误时重试。
9. stale_schedule ： 如果延迟的工作无法执行，则重试。
10. job_execution_timeout ： 如果脚本超过了为作业设置的最大执行时间，则重试。
11. archived_failure ： 如果作业被归档，无法运行，则重试。
12. unmet_prerequisites ： 如果作业未能完成先决条件任务，则重试。
13. scheduler_failure ： 如果调度器未能将作业分配给运行器，则重试。
14. data_integrity_failure ： 如果检测到有结构完整性问题，则重试。

14.2、案例

test:
  script: rspec
  retry: 2

14.3、案例

下面这个例子只有当运行器系统出现故障时才能最多重试两次

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

14.4、案例

如果上面例子中出现的是其他故障，那么作业不会重试。
为了针对多种重试情形，我们可以使用矩阵形式罗列出错误情形，如下示例：

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

15、timeout

timeout允许你为一个特定的工作配置一个超时。

15.1、案例

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

作业级超时可以超过项目级超时，但不能超过Runner特定的超时。

16、parallel

1. 并行允许您配置并行运行的作业实例数。
2. 该值必须大于或等于2 且小于或等于 50。
3. 这将创建同一作业的N个并行运行的实例。它们按顺序从 job_name 1/N 命名到 job_name N/N。
4. 对于每个作业，CI_NODE_INDEX 和 CI_NODE_TOTAL 环境变量被设置。

16.1、案例

标记一个作业为并行运行

test:
  script: rspec
  parallel: 5

17、trigger

1. trigger 是应对那些更加复杂的CICD流程，如多流水线，父子流水线，使用它可以定义一个下游的流水线
2. 配置了trigger的任务是不能跑脚本的，就是说不能定义script， before_script， 和 after_script

17.1、案例

这个是一个多项目流水线

rspec:
  stage: test
  script: bundle exec rspec

staging:
  stage: deploy
  trigger: my/deployment

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

17.2、案例

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

rspec:
  stage: test
  script: bundle exec rspec

staging:
  stage: deploy
  trigger:
    project: my/deployment
    branch: stablez

18、include

1. 你可以允许包含外部YAML文件。
2. include要求外部YAML文件的扩展名是.yml或.yaml，否则外部文件将不会被包含。
3. include中定义的文件是
   1. 与.gitlab-ci.yml中的文件进行深度合并。
   2. 总是先评估并与.gitlab-ci.yml中的内容合并，无论include关键字的位置如何
4. include 支持四种 include 方法
   1. local
   2. file
   3. template
   4. remote

18.1、include:local

1. include:local包括一个与.gitlab-ci.yml相同的存储库的文件。
2. 它使用相对于根目录(/)的全路径进行引用。

示例

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

18.2、include:file

1. 要包含同一GitLab实例下其他私有项目的文件，请使用include:file。
2. 这个文件是使用相对于根目录(/)的全路径来引用的。

示例

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

你也可以指定ref，默认是项目的HEAD。

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'

18.3、include:template

可用于包含 GitLab 附带的 .gitlab-ci.yml 模板。

示例

# File sourced from GitLab's template collection
include:
  - template: Auto-DevOps.gitlab-ci.yml

多个include:template文件。

include:
  - template: Android-Fastlane.gitlab-ci.yml
  - template: Auto-DevOps.gitlab-ci.yml

18.4、include:remote

1. 可用于包含来自不同位置的文件
2. 使用 HTTP/HTTPS，使用完整 URL 引用。
3. 远程文件必须可通过简单的 GET 请求公开访问，因为不支持远程 URL 中的身份验证模式。

示例

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

19、extends

1. 用于定义当前作业从哪里继承。
2. 它是使用YAML锚点的替代方案，更加灵活、可读性强。

19.1、案例

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches

rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

在上面的例子中，rspec作业继承了.test模板作业。

GitLab将根据键值进行反向深度合并。GitLab将

1. 递归地将rspec的内容合并到.test中。
2. 不合并键的值。

这会产生以下 rspec 作业：

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

脚本：rake test 已被脚本：rake rspec 覆盖。

如果您确实想包含 rake 测试，请参阅 before_script 和 after_script。

19.2、extends 与 include 结合使用跨配置文件

19.2.1、案例

例如，如果您有一个本地 included.yml 文件：

.template:
  script:
    - echo Hello!

然后，在.gitlab-ci.yml中你可以这样使用它。

include: included.yml

useTemplate:
  image: alpine
  extends: .template

这将运行一个名为useTemplate的作业，运行.template作业中定义的echo Hello！，并使用本地作业中定义的alpine Docker镜像。

20、pages

1. pages是一个特殊的作业，用于向GitLab上传静态内容，可以用来为你的网站提供服务。
2. 它有一个特殊的语法，所以必须满足以下两个要求。
   1. 任何静态内容必须放在public/目录下。
   2. 必须定义有通往public/目录的路径的工件。

20.1、案例

下面的例子只是把所有的文件从项目的根部移到public/目录下。

pages:
  stage: deploy
  script:
    - mkdir .temp
    - cp -r * .temp
    - mv .temp public
  artifacts:
    paths:
      - public
  only:
    - test

21、interruptible

1. 表明该任务是否能够被新的流水线打断，取消。
2. 默认为false， 即不可取消，不可被打断。
3. 当启用时，同一分支上的管道将被取消。
   1. 它被一个较新的流水线运行而变得多余了。
   2. 要么所有作业都被设置为可中断，要么任何不可中断的作业都没有开始。
   3. 正在进行的作业总是被认为是可中断的。
   4. 一旦一个不可中断的作业正在运行，无论最终作业的状态如何，管道都不会被取消。
4. 将作业设置为可中断的，一旦开始就可以安全地取消的作业(例如，一个构建作业)。

21.1、案例

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled， this step will never be canceled， even though set as interruptible."
  interruptible: true

1. 如果仅仅是step-1正在运行或者pending，那么流水线可能会被新流水打断。
2. 如果一旦step-2开始运行后，该流水线就不会再被新的流水线打断。

22、resource_group

1. 有时在一个环境中同时运行多个作业或管道会导致部署过程中出现错误。为了避免这些错误，可以使用 resource_group 属性来确保 Runner 不会同时运行某些作业。
2. 当.gitlab-ci.yml中为一个作业定义了resource_group键时，作业的执行在同一项目的不同管道中是相互排斥的。
3. 如果属于同一资源组的多个作业同时排队，只有其中一个作业会被Runner选中，其他作业将等待，直到资源_组空闲。

22.1、案例

deploy-to-production:
  script: deploy
  resource_group: production