21.云原生之GitLab pipline语法（CI基础）

云原生专栏大纲

gitlab docs官网

gitlab-ci.yml 介绍

gitlab-ci.yml 是 GitLab CI/CD 的配置文件，用于定义项目的持续集成和持续交付流程。它采用 YAML 格式，位于项目的根目录或指定的目录中。
gitlab-ci.yml 文件包含了一系列的作业（jobs）和阶段（stages），定义了项目在不同情况下的构建、测试、部署等操作。以下是一些常见的 gitlab-ci.yml 配置项：

• image：指定用于作业执行的 Docker 镜像。可以选择现有的镜像，也可以自定义镜像。
• stages：定义项目的阶段顺序。每个阶段包含一组作业。
• before_script：在每个作业执行之前运行的脚本命令。可以用于设置环境、安装依赖等操作。
• after_script：在每个作业执行之后运行的脚本命令。可以用于清理环境、收集结果等操作。
• variables：定义作业的环境变量。可以在作业的脚本中使用这些变量。
• jobs：定义项目的作业。每个作业包含一个或多个脚本命令，用于执行具体的操作。
  • script：指定作业要执行的脚本命令。可以是单个命令或多个命令的序列。
  • artifacts：定义作业产生的构建产物，可以在后续的作业中使用。
  • only 和 except：指定作业执行的条件。可以基于分支、标签、变量等进行条件判断。

gitlab-ci.yml 文件的配置可以根据项目的需求进行自定义。你可以定义多个作业和阶段，根据需要设置依赖关系，以及在不同的条件下执行不同的操作。这使得你能够构建灵活、可扩展的 CI/CD 流程，提高开发效率和软件质量。

需要注意的是，一旦 gitlab-ci.yml 文件发生变化，GitLab 会自动检测并开始执行新的 CI/CD 流程。执行结果和日志可以在 GitLab 的界面中查看和分析。

GitLab中语法检测

1. 进入CI/CD->配置检查

2. 语法检测（这儿可以像写代码一样测试脚本）

gitlab-ci.yml 语法

官网gitlab-ci.yml语法，官网在线文档维护的最低版本是14.10，若想看更低版本文GitLab Docs历史版本。

# 较老版本
docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs:11.1
# 较新版本
docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs/archives:15.5

GitLab CI/CD 示例：http://localhost:4000/11.1/ee/ci/examples/README.html
gitlab-ci.yml 语法参考：http://localhost:4000/11.1/ee/ci/yaml/README.html

常用关键字：

job/script/before_script/after_script/stages/stage/variables/tags/allow_failure/when/retry/timeout/parallel

job无标签，runner有标签，流水线job被卡住情况：

登录gitlab修改runner配置勾选运行没有标签的作业：

job定义作业

job至少包含一个script

job1:
  script: "execute-script-for-job1"

job2:
  script: 
    - uname -a
    - bundle exec respec

注意:有时, script命令将需要用单引号或双引号引起来.例如,包含冒号命令(:)需要加引号,以便被包裹的YAML解析器知道来解释整个事情作为一个字符串，而不是一个"键：值"对.使用特殊字符时要小心：},[,],&,*,#,?,1,-,<,>,=!,8,@,

job下能使用的参数关键字：

关键词	必填	描述
script	yes	定义由 Runner 执行的 shell 脚本
image	no	使用 docker 镜像，在使用 Docker 镜像中介绍
services	no	使用 Docker 服务，如使用 Docker 映像中所述
stage	no	定义作业阶段（默认值：test)
type	no	别名stage
variables	no	在作业级别定义作业变量
only	no	定义为其创建作业的 git ref 列表
except	no	定义未为其创建作业的 git ref 列表
tags	no	定义用于选择 Runner 的标签列表
allow_failure	no	允许作业失败。失败的作业对提交状态没有影响
when	no	定义何时运行作业。可以是 、 或on_successon_failurealwaysmanual
dependencies	no	定义作业所依赖的其他作业，以便在它们之间传递工件
artifacts	no	定义作业工件列表
cache	no	定义应在后续运行之间缓存的文件列表
before_script	no	覆盖在作业之前执行的一组命令
after_script	no	覆盖作业后执行的一组命令
environment	no	定义此作业执行部署的环境的名称
coverage	no	定义给定作业的代码覆盖率设置
retry	no	定义作业在发生故障时可以自动重试的次数

before_script和after_script

before_script用于定义应先运行的命令 作业，包括部署作业，但在还原项目之后。 这可以是数组或多行字符串。
after_script用于定义将在 all 之后运行的命令 作业，包括失败的作业。这必须是数组或多行字符串。

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

stages:
  - job1
  - job2

job1:
  stage: job1
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: job2
  script:
    - echo "job2 script... "

before_script失败导致整个作业失败，其他作业将不再执行。作业失败不会影响after_script运行。

job1运行日志：没有执行全局before_script和after_script

job2运行日志：执行全局before_script和after_script

stages定义阶段

stages全局定义阶段执行顺序；stages在job中定义，指定job在那个阶段。

1. 同一阶段的作业并行运行。
2. 下一阶段的作业在上一阶段的作业之后运行 成功完成。

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

# 全局定义阶段执行顺序
stages:
  - build
  - test
  - deploy

job1:
  stage: build
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: test
  script:
    - echo "job2 script... "

job3:
  stage: test
  script:
    - echo "job3 script... "

job4:
  stage: deploy
  script:
    - echo "job3 script... "

job2和job3在同一stage，作业并行执行

并行需要修改gitlab-runner中 /etc/gitlab-runner/config.toml下concurrent并发数配置，该配置默认1。修改后自动生效。

3. .pre和.post

.pre：在流水线运行之前运行； .post： 在流水线运行之后运行

pre:
  stage: .pre
  script:
    - echo "pre script... "
post:
  stage: .post
  script:
    - echo "post script... "

tages指定runner

用于指定job在那个runner上执行

stages:
  - build
  - deploy

build_job:
  stage: build
  tags:
    - build
  only: 
    - master
  script:
    - echo "Building the project... "


deploy_job:
  stage: deploy
  tags:
    - deploy
  only:
    - master
  script:
    - echo "Deploying the project..."

查看build和deploy作业日志验证是否在指定runner上运行
build_job日志：runner使用的3a8211f3

deploy_job日志：runner使用的c62726d6

跟下述创建的runner令牌能对应上

allow_failure运行失败

allow_failure允许作业失败，默认值为false。启用后，如果作业失败，该作业将在用户界面中显示橙色警告。但是，管道的逻辑流程将认为作业成功/通过，并且不会被阻塞。假设所有其他作业均成功，则该作业的阶段及其管道将显示相同的橙色警告。但是，关联的提交将被标记为"通过"，而不会发出警告。

下述job2中script下脚本写错模拟失败情况：

before_script:
  - echo "global before script... "
after_script:
  - echo "global before after_script... "

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  before_script:
    - echo "job1 before_script... "
  script:
    - echo "job1 script... "
  after_script:
    - echo "job1 after_script... "
job2:
  stage: test
  script:
    - ech "job2 script... "
  allow_failure: true

job3:
  stage: test
  script:
    - echo "job3 script... "

job4:
  stage: deploy
  script:
    - echo "job3 script... "

when控制作业运行

1. on_success ：仅当前几个阶段的所有作业时才执行作业 成功。这是默认设置。
2. on_failure ：仅当先前阶段的至少一个作业时失败才执行作业。
3. always ：总是执行作业，而不考虑先前阶段的作业状态。
4. manual ：手动执行作业（在 GitLab 8.10 中添加）。请阅读下面的手动操作。
5. delayed：延迟执行作业

stages:
  - build
  - test
  - deploy


job_ok:
  stage: build
  script:
    - echo "job_ok... "

on_failure_job_skip:
  stage: test
  script:
    - echo "on_failure_job_skip... "
  when: on_failure

on_success_job_run:
  stage: test
  script:
    - echo "on_success_job_run... "
  when: on_success

job_err:
  stage: test
  script:
    - ech "on_success_job_run... "


on_failure_job_run:
  stage: deploy
  script:
    - echo "on_failure_job_run... "
  when: on_failure

注意当错误执行使用allow_failure: true，stage会认为是正确，验证如下on_failure_job_run没执行

retry重试

配置在失败的情况下重试作业的次数。重试成功或达到最大重试次数就在执行该job

job_err:
  stage: test
  script:
    - ech "on_success_job_run... "
 # retry: 2 # 11.1.4版本使用该语法，还不支持when
  retry:
    max: 2
    when:
    - script_failure

重试错误类型

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 ：检测到结构完整性问题。

timeout超时

该标签在小编安装11.1版本中没有，但是介绍下。
作业级别超时配置：

job_ok:
  stage: build
  script:
    - echo "job_ok... "
  timeout: 3h 30m  # 作业级别超时

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

项目超时时间配置如下：

runner超时配置：

如果小于项目定义超时时间将具有优先权。此功能可用于通过设置大超时（例如一个星期）来防止SharedRunner被项目占用。未配置时，Runner将不会覆盖项目超时。

超时时间到底哪个生效？

当项目和runner都设置了超时时间，那个小那个生效。runner未设置，项目设置超时时间，项目设置生效。

parallel并行作业

1. 配置要并行运行的作业实例数,此值必须大于或等于2并且小于或等于50。
2. 这将创建N个并行运行的同一作业实例.它们从job_name 1/N到job_name N/N依次命名。

job_ok:
  stage: build
  script:
    - echo "job_ok... "
  parallel: 5

only & except

only和except是两个参数用分支策略来限制jobs构建：

1. only定义哪些分支和标签的git项目将会被job执行。
2. except定义哪些分支和标签的git项目将不会被job执行。

job:
  # use regexp
  only:
    - /^issue-.*$/
  # use special keyword
  except:
    - 分支名

rules

rules允许_按顺序_评估单个规则对象的列表，直到一个匹配并为作业动态提供属性.

在 GitLab 12.3 中引入。请注意， rules不能与only/except组合使用。

variables:
  DOMAIN: xxx.com

codescan:
  stage: test
  tags:
    - build
  script:
    - echo "codescan"
    - sleep 5;
  #parallel: 5
  rules:
    - exists:
      - Jenkinsfile
    - changes:
      - Jenkinsfile
    - if: '$DOMAIN == "xxx.com"'
      when: manual
    - when: on_success
     allow_failure: true

rules:if

如果DOMAIN的值匹配，则需要手动运行。不匹配on_success。 条件判断从上到下，匹配即停止。多条件匹配可以使用&& ||

rules:changes

接受文件路径数组。 如果提交中Jenkinsfile文件发生的变化则为true。

rules:exists

接受文件路径数组。当仓库中存在指定的文件时操作。

rules:allow_failure

使用allow_failure: true rules:在不停止管道本身的情况下允许作业失败或手动作业等待操作.

cache 缓存

用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径。不要使用缓存在阶段之间传递工件，因为缓存旨在存储编译项目所需的运行时依赖项。
如果在job范围之外定义了cache ，则意味着它是全局设置，所有job都将使用该定义。如果未全局定义或未按job定义则禁用该功能。

cache:paths

使用paths指令选择要缓存的文件或目录，路径是相对于项目目录，不能直接链接到项目目录之外。
$CI_PROJECT_DIR 项目目录
在job build中定义缓存，将会缓存target目录下的所有.jar文件。

build:
  script: test
  cache:
    paths:
      - target/*.jar

当在全局定义了cache:paths会被job中覆盖。以下实例将缓存binaries目录。

cache:
  paths:
    - my/files

build:
  script: echo "hello"
  cache:
    key: build
    paths:
      - target/

由于缓存是在job之间共享的，如果不同的job使用不同的路径就出现了缓存覆盖的问题。如何让不同的job缓存不同的cache呢？设置不同的cache:key。

---

cache:key 缓存标记

为缓存做个标记，可以配置job、分支为key来实现分支、作业特定的缓存。为不同 job 定义了不同的 cache:key 时， 会为每个 job 分配一个独立的 cache。cache:key变量可以使用任何预定义变量，默认default ，从GitLab 9.0开始，默认情况下所有内容都在管道和作业之间共享。
按照分支设置缓存

cache:
  key: ${CI_COMMIT_REF_SLUG}

files： 文件发生变化自动重新生成缓存(files最多指定两个文件)，提交的时候检查指定的文件。
根据指定的文件生成密钥计算SHA校验和，如果文件未改变值为default。

cache:
  key:
    files:
      - Gemfile.lock
      - package.json
  paths:
    - vendor/ruby
    - node_modules

prefix: 允许给定prefix的值与指定文件生成的秘钥组合。
在这里定义了全局的cache，如果文件发生变化则值为 rspec-xxx111111111222222 ，未发生变化为rspec-default。

cache:
  key:
    files:
      - Gemfile.lock
    prefix: ${CI_JOB_NAME}
  paths:
    - vendor/ruby

rspec:
  script:
    - bundle exec rspec

例如，添加$CI_JOB_NAME prefix将使密钥看起来像： rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5 ，并且作业缓存在不同分支之间共享，如果分支更改了Gemfile.lock ，则该分支将为cachefiles具有新的SHA校验和. 将生成一个新的缓存密钥，并为该密钥创建一个新的缓存. 如果Gemfile.lock未发生变化 ，则将前缀添加default ，因此示例中的键为rspec-default 。

---

cache:policy 策略

默认：在执行开始时下载文件，并在结束时重新上传文件。称为” pull-push缓存策略.
policy: pull 跳过下载步骤
policy: push 跳过上传步骤

stages:
  - setup
  - test

prepare:
  stage: setup
  cache:
    key: gems
    paths:
      - vendor/bundle
  script:
    - bundle install --deployment

rspec:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - bundle exec rspec ...

artifacts

用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。作业完成后，工件将被发送到GitLab，并可在GitLab UI中下载。

artifacts:paths

路径是相对于项目目录的，不能直接链接到项目目录之外。
将制品设置为target目录

artifacts:
  paths:
    - target/

禁用工件传递

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

您可能只想为标记的发行版创建构件，以避免用临时构建构件填充构建服务器存储。仅为标签创建工件（ default-job不会创建工件）：

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

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

---

artifacts:expose_as

关键字expose_as可用于在合并请求 UI中公开作业工件。
例如，要匹配单个文件：

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

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

制品浏览

请注意以下几点：

• 每个合并请求最多可以公开10个作业工件。
• 如果指定了目录，那么如果目录中有多个文件，则该链接将指向指向作业工件浏览器。
• 如果开启GitlabPages可以对.html .htm .txt .json .log扩展名单个文件工件渲染工件。

---

artifacts:name

通过name指令定义所创建的工件存档的名称。可以为每个档案使用唯一的名称。 artifacts:name变量可以使用任何预定义变量。默认名称是artifacts，下载artifacts改为artifacts.zip。
使用当前作业的名称创建档案

job:
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - binaries/

使用内部分支或标记的名称（仅包括binaries目录）创建档案，

job:
  artifacts:
    name: "$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

使用当前作业的名称和当前分支或标记（仅包括二进制文件目录）创建档案

job:
  artifacts:
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

要创建一个具有当前阶段名称和分支名称的档案

job:
  artifacts:
    name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
    paths:
      - binaries/

---

artifacts:when

用于在作业失败时或尽管失败而上传工件。on_success仅在作业成功时上载工件。这是默认值。on_failure仅在作业失败时上载工件。always 上载工件，无论作业状态如何。
要仅在作业失败时上传工件：

job:
  artifacts:
    when: on_failure

---

artifacts:expire_in

制品的有效期，从上传和存储到GitLab的时间开始算起。如果未定义过期时间，则默认为30天。
expire_in的值以秒为单位的经过时间，除非提供了单位。可解析值的示例：

‘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’

一周后过期

job:
  artifacts:
    expire_in: 1 week

---

artifacts:reports

用于从作业中收集测试报告，代码质量报告和安全报告. 在GitLab的UI中显示这些报告。
**注意：**无论作业结果（成功或失败），都将收集测试报告。

artifacts:reports: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_as: 'artifact 1'
    paths:
      - target/*.jar
    reports:
      junit: target/surefire-reports/TEST-*.xml

**注意：**如果您使用的JUnit工具导出到多个XML文件，则可以在一个作业中指定多个测试报告路径，它们将被自动串联到一个文件中. 使用文件名模式（ junit: rspec-.xml ），文件名数组（ junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml] ）或其组合（ junit: [rspec.xml, test-results/TEST-.xml] ）。


如果无法显示此页面，需要更改系统设置。此选项可能会加大资源占用，默认禁用了需要启用。

登录gitlab
su -  git
$ gitlab-rails console
--------------------------------------------------------------------------------
 GitLab:       12.9.0 (9a382ff2c82) FOSS
 GitLab Shell: 12.0.0
 PostgreSQL:   10.12
--------------------------------------------------------------------------------
Feature.enable(:junit_pipeline_view)Loading production environment (Rails 6.0.2)
irb(main):001:0>
irb(main):002:0>
irb(main):003:0> Feature.enable(:junit_pipeline_view)
=> true
irb(main):004:0>

参考链接：https://docs.gitlab.com/ee/ci/junit_test_reports.html

---

artifacts:reports:cobertura

收集的Cobertura覆盖率报告将作为工件上传到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_as: 'artifact 1'
    paths:
      - target/*.jar
    reports:
      junit: target/surefire-reports/TEST-*.xml
      cobertura: target/site/cobertura/coverage.xml

$ gitlab-rails console
--------------------------------------------------------------------------------
 GitLab:       12.9.0 (9a382ff2c82) FOSS
 GitLab Shell: 12.0.0
 PostgreSQL:   10.12
--------------------------------------------------------------------------------


Loading production environment (Rails 6.0.2)
irb(main):001:0>
irb(main):002:0>
irb(main):003:0> Feature.enable(:coverage_report_view)
=> true

maven集成cobertura插件

       
  
  
    org.codehaus.mojo  
    cobertura-maven-plugin  
    2.7  
      
        
          html  
          xml  
        
  	  
         
  

执行 mvn cobertura:cobertura 运行测试并产生 Cobertura 覆盖率报告。
参考链接：https://docs.gitlab.com/12.9/ee/user/project/merge_requests/test_coverage_visualization.html
备注实验未做出效果，具体问题待排查。

---

dependencies

定义要获取工件的作业列表，只能从当前阶段之前执行的阶段定义作业。定义一个空数组将跳过下载该作业的任何工件不会考虑先前作业的状态，因此，如果它失败或是未运行的手动作业，则不会发生错误。

如果设置为依赖项的作业的工件已过期或删除，那么依赖项作业将失败。

needs 并行阶段

可无序执行作业，无需按照阶段顺序运行某些作业，可以让多个阶段同时运行。

stages:
  - build
  - test
  - deploy

module-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10
    
module-b-build:
  stage: build
  script: 
    - echo "hello3b"
    - sleep 10

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: ["module-a-build"]
    
module-b-test:
  stage: test
  script: 
    - echo "hello3b"
    - sleep 10
  needs: ["module-b-build"]

如果needs:设置为指向因only/except规则而未实例化的作业，或者不存在，则创建管道时会出现YAML错误。
暂时限制了作业在needs:可能需要的最大作业数分配,ci_dag_limit_needs功能标志已启用（默认）分配10个，如果功能被禁用为50。

Feature::disable(:ci_dag_limit_needs)   # 50
Feature::enable(:ci_dag_limit_needs)  #10

---

制品下载

在使用needs，可通过artifacts: true或artifacts: false来控制工件下载。 默认不指定为true。

module-a-test:
  stage: test
  script: 
    - echo "hello3a"
    - sleep 10
  needs: 
    - job: "module-a-build"
      artifacts: true

相同项目中的管道制品下载,通过将project关键字设置为当前项目的名称，并指定引用，可以使用needs从当前项目的不同管道中下载工件。在下面的示例中，build_job将使用other-refref下载最新成功的build-1作业的工件：

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: group/same-project-name
      job: build-1
      ref: other-ref
      artifacts: true

不支持从parallel:运行的作业中下载工件。

---

include

https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
可以允许引入外部YAML文件，文件具有扩展名.yml或.yaml 。使用合并功能可以自定义和覆盖包含本地定义的CI / CD配置。相同的job会合并，参数值以源文件为准。

local

引入同一存储库中的文件，使用相对于根目录的完整路径进行引用，与配置文件在同一分支上使用。
ci/localci.yml: 定义一个作业用于发布。

stages:
  - deploy
  
deployjob:
  stage: deploy
  script:
    - echo 'deploy'

.gitlab-ci.yml 引入本地的CI文件’ci/localci.yml’。

include:
  local: 'ci/localci.yml'
  

stages:
  - build
  - test
  - deploy
  

buildjob:
  stage: build
  script: ls
  
 
testjob:
  stage: test
  script: ls

效果

---

file

包含来自另一个项目的文件

include:
  - project: demo/demo-java-service
    ref: master
    file: '.gitlab-ci.yml'

template

只能使用官方提供的模板 https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates

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

remote

用于通过HTTP / HTTPS包含来自其他位置的文件，并使用完整URL进行引用. 远程文件必须可以通过简单的GET请求公开访问，因为不支持远程URL中的身份验证架构。

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

---

extends

继承模板作业

stages:
  - test
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches

testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC

合并后

testjob:
  stage: test
  script: mvn clean test
  only:
    variables:
      - $RSPEC
    refs:
      - branches

---

extends & include

aa.yml

#stages:
#  - deploy
  
deployjob:
  stage: deploy
  script:
    - echo 'deploy'
  only:
    - dev

.template:
  stage: build
  script: 
    - echo "build"
  only:
    - master

include:
  local: 'ci/localci.yml'

stages:
  - test
  - build 
  - deploy
  
variables:
  RSPEC: 'test'

.tests:
  script: echo "mvn test"
  stage: test
  only:
    refs:
      - branches

testjob:
  extends: .tests
  script: echo "mvn clean test"
  only:
    variables:
      - $RSPEC
      

newbuildjob:
  script:
    - echo "123"
  extends: .template

这将运行名为useTemplate的作业，该作业运行echo Hello! 如.template作业中所定义，并使用本地作业中所定义的alpine Docker映像.

---

trigger 管道触发

当GitLab从trigger定义创建的作业启动时，将创建一个下游管道。允许创建多项目管道和子管道。将trigger与when:manual一起使用会导致错误。
多项目管道： 跨多个项目设置流水线，以便一个项目中的管道可以触发另一个项目中的管道。[微服务架构]
父子管道: 在同一项目中管道可以触发一组同时运行的子管道,子管道仍然按照阶段顺序执行其每个作业，但是可以自由地继续执行各个阶段，而不必等待父管道中无关的作业完成。

多项目管道

当前面阶段运行完成后，触发demo/demo-java-service项目master流水线。创建上游管道的用户需要具有对下游项目的访问权限。如果发现下游项目用户没有访问权限以在其中创建管道，则staging作业将被标记为_失败_。

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    project: demo/demo-java-service
    branch: master
    strategy: depend

project关键字，用于指定下游项目的完整路径。该branch关键字指定由指定的项目分支的名称。使用variables关键字将变量传递到下游管道。 全局变量也会传递给下游项目。上游管道优先于下游管道。如果在上游和下游项目中定义了两个具有相同名称的变量，则在上游项目中定义的变量将优先。默认情况下，一旦创建下游管道，trigger作业就会以success状态完成。strategy: depend将自身状态从触发的管道合并到源作业。

在下游项目中查看管道信息

在此示例中，一旦创建了下游管道，该staging将被标记为成功。

父子管道

创建子管道ci/child01.yml

stages:
  - build

child-a-build:
  stage: build
  script: 
    - echo "hello3a"
    - sleep 10

在父管道触发子管道

staging2:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: 
    include: ci/child01.yml  
    strategy: depend

image

准备工作注册docker类型的runner

gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
  --url "http://192.168.1.33:30088/" \
  --registration-token "xxx" \
  --description "docker-runner" \
  --tag-list "newdocker" \
  --run-untagged="true" \
  --locked="false" \
  --docker-privileged \ 
  --access-level="not_protected"

[[runners]]
  name = "docker-runner"
  url = "http://192.168.1.33:30088/"
  token = "xxx"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
  [runners.docker]
    pull_policy = "if-not-present"
    tls_verify = false
    image = "alpine:latest"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

默认在注册runner的时候需要填写一个基础的镜像，请记住一点只要使用执行器为docker类型的runner所有的操作运行都会在容器中运行。 如果全局指定了images则所有作业使用此image创建容器并在其中运行。 全局未指定image，再次查看job中是否有指定，如果有此job按照指定镜像创建容器并运行，没有则使用注册runner时指定的默认镜像。

#image: maven:3.6.3-jdk-8

before_script:
  - ls
  
  
build:
  image: maven:3.6.3-jdk-8
  stage: build
  tags:
    - newdocker
  script:
    - ls
    - sleep 2
    - echo "mvn clean "
    - sleep 10

deploy:
  stage: deploy
  tags:
    - newdocker
  script:
    - echo "deploy"

---

services

工作期间运行的另一个Docker映像，并link到image关键字定义的Docker映像。这样，您就可以在构建期间访问服务映像.
服务映像可以运行任何应用程序，但是最常见的用例是运行数据库容器，例如mysql 。与每次安装项目时都安装mysql相比，使用现有映像并将其作为附加容器运行更容易，更快捷。

services:
  - name: mysql:latest
    alias: mysql-1

---

environment

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production
    url: https://prod.example.com

---

inherit

使用或禁用全局定义的环境变量（variables）或默认值(default)。
使用true、false决定是否使用，默认为true

inherit:
  default: false
  variables: false

继承其中的一部分变量或默认值使用list

inherit:
  default:
    - parameter1
    - parameter2
  variables:
    - VARIABLE1
    - VARIABLE2