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历史版本。GitLabPipeline语法。

# 较老版本
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

docker run -it --rm -p 4000:4000 registry.gitlab.com/gitlab-org/gitlab-docs:11.1

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控制作业运行

• on_success（默认）：之前所有job执行成功，才执行，否则跳过执行
• on_failure：之前有job执行失败，才执行
• never：无论作业在早期阶段的状态如何，都不要运行作业。
• always：无论作业在早期阶段的状态如何，都运行作业。
• manual：仅在手动触发时运行作业。
• 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超时

作业级别超时配置：

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

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

项目超时时间配置如下：

runner超时配置：

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

超时时间到底哪个生效？

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

parallel并行作业

用于在单个管道中并行多次运行作业。在 GitLab 15.9 中引入，最大值从 50 增加到 200。

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

only & except

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

注意：官网提示已废弃，但还能使用。推荐使用rules代替。

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

rules

用于在管道中包含或排除作业。job中按顺序执行，直到匹配到

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

匹配规则：下述规则可以嵌套使用

规则	描述
rules:if	true：将作业添加到管道中 若if后是when: never，跳过job
ules:changes或 rules:changes:paths	接受文件路径数组。 检查文件是否改变，文件改变则为true作业执行
rules:exists	接受文件路径数组。 当仓库中存在指定的文件时执行作业。
rules:allow_failure	在不停止管道本身的情况下允许作业失败或手动作业等待操作

stages:
  - build
  - test
  - deploy

variables:
  NAME: gitlab

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

rules-if-true:
  stage: test
  script:
    - echo "rules-if-true... "
  rules:
    - if: $NAME == "gitlab"

rules-if-when-never:
  stage: test
  script:
    - echo "rules-if-when-never... "
  rules:
    - if: $NAME == "gitlab"
      when: never

rules-changes-true:
  stage: test
  script:
    - echo "rules-changes-true... "
  rules:
    - changes:
      - Jenkinsfile

rules-changes-false:
  stage: test
  script:
    - echo "rules-changes-false... "
  rules:
    - changes:
      - pom.xml
  allow_failure: true

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

修改Jenkinsfile文件提交：rules-changes-false和rules-if-when-never没有执行

修改pom.xml提交：rules-changes-true和rules-if-when-never没执行

cache 缓存

在 GitLab 15.0 中引入，缓存不会在受保护和不受保护的分支之间共享。

用来指定需要在job之间缓存的文件或目录。只能使用该项目工作空间内的路径（及gitlab-runner内部缓存）。不要使用缓存在阶段之间传递工件，因为缓存旨在存储编译项目所需的运行时依赖项。
如果在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/

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/

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

cache:key 缓存标记

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

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/

进入gitlab-runner终端查看缓存：

cache🔑files

在 GitLab 12.5 中引入。

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

  cache:
    key:
      files:
        - pom.xml
    paths:
      - kustomize/

进入gitlab-runner终端查看缓存：

cache🔑prefix

prefix: 允许给定prefix的值与指定文件生成的秘钥组合。

  cache:
    key:
      files:
        - pom.xml
      prefix: $CI_JOB_NAME
    paths:
      - kustomize/

cache:policy 策略

默认：在执行开始时下载文件，并在结束时重新上传文件。称为pull-push缓存策略.
policy: pull ：将作业设置为仅在作业启动时下载缓存，但从不上传更改
policy: push ： 将作业设置为仅在作业完成时上传缓存，但从不下载 缓存

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

artifacts

用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。作业完成后，工件将被发送到GitLab，并可在GitLab UI中下载。
在GitLab Runner中，Artifacts（构件）是指在CI/CD流程中生成的文件或目录，它们可以被传递、存储和共享。Artifacts通常用于将构建产物、测试报告、生成的文档等相关文件保存下来，以便后续的步骤或阶段可以使用或查看。
当作业执行完成后，你可以将指定的文件或目录定义为Artifacts，并将其上传到GitLab服务器上。这些Artifacts可以在GitLab界面中查看，并且可以被其他作业或阶段使用。
Artifacts提供了以下优点和用途：

1. 持久化构建结果：通过将构建产物定义为Artifacts，你可以将构建生成的文件或目录保留下来，即使作业执行完毕后也可以随时访问。这对于构建产物的后续使用或分析非常有用。
2. 共享和传递数据：Artifacts可以在不同的作业或阶段之间传递数据。例如，一个作业可以生成一些文件，然后将这些文件定义为Artifacts，接下来的作业可以通过下载这些Artifacts来使用这些文件。
3. 查看和下载：通过GitLab界面，你可以方便地查看和下载Artifacts。这使得团队成员可以轻松访问和检查构建结果、测试报告等。

属性	描述
paths	指定要作为Artifacts上传的文件或目录的路径。 路径是相对于项目目录的，不能直接链接到项目目录之外。
expose_as	指定Artifacts在GitLab界面中显示的名称。
name	指定Artifacts的名称。
when	指定Artifacts何时上传到GitLab服务器的条件。
expire_in	指定Artifacts的过期时间。从上传和存储到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’
reports	定义生成的报告文件。

cache-job:
  stage: build
  script:
    - echo "job_ok... "
  cache:
    key: kustomize
    paths:
      - kustomize/
  artifacts:
    paths:
      - kustomize/
    expose_as: gitlab-kustomize
    name: my-kustomize
    when: always
    expire_in: 1 week
    reports:
      junit: junit.xml 

上述示例中，job1作业在构建过程中生成了一个build/目录和一个test_results.xml文件。通过artifacts关键字，将这些构建产物定义为Artifacts。在作业执行完成后，这些Artifacts将被上传到GitLab服务器上，并可以在后续的作业中使用或下载。
通过Artifacts，你可以方便地管理和共享CI/CD流程中的产物，提高团队的协作和效率。

查看下载压缩包中内容：下载压缩包名my-kustomize.zip

gitlab中查看artifacts

禁用工件传递

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

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 Runner中，trigger关键字用于触发另一个项目的CI/CD流程。通过使用trigger，你可以在一个项目的CI/CD流程中触发另一个项目的流程，实现项目间的集成和协作。允许创建多项目管道和子管道。将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类型执行器，只要使用执行器为docker类型的runner所有的操作运行都会在容器中运行。

mage关键字用于指定在CI/CD作业中使用的Docker镜像。通过使用image，你可以为作业提供一个特定的环境，其中包含所需的软件、工具和依赖项。让我们来详细了解image的用法和功能。
image存在的地方：

1. 注册runner时指定
2. gitlab-ci.yaml中全局指定
3. gitlab-ci.yaml中job指定

如果全局指定了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

services关键字用于指定在CI/CD作业中需要运行的附加服务。通过使用services，你可以在作业执行期间启动和访问其他容器化的服务，以满足作业的需求。
服务映像可以运行任何应用程序，但是最常见的用例是运行数据库容器，例如mysql 。与每次安装项目时都安装mysql相比，使用现有映像并将其作为附加容器运行更容易，更快捷。

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

---

environment

environment关键字用于定义CI/CD作业的环境变量。环境变量是在作业执行期间可用的键值对，用于配置作业的行为和访问外部资源。

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment: # 定义环境变量
    name: production
    url: https://prod.example.com

常用预定义环境变量：

CI_COMMIT_REF_NAME：作业所在的分支或标签的名称。
CI_COMMIT_REF_SLUG：作业所在的分支或标签的名称，经过URL编码。
CI_COMMIT_SHA：作业所在的提交的SHA值。
CI_COMMIT_SHORT_SHA：作业所在的提交的短SHA值（前7个字符）。
CI_COMMIT_MESSAGE：作业所在的提交的提交消息。
CI_COMMIT_TITLE：作业所在的提交的提交标题（第一行）。
CI_COMMIT_DESCRIPTION：作业所在的提交的提交描述（除了第一行之外的部分）。
CI_JOB_ID：作业的唯一标识符。
CI_JOB_NAME：作业的名称。
CI_PIPELINE_ID：作业所在的流水线的唯一标识符。
CI_PROJECT_ID：作业所在的项目的唯一标识符。
CI_PROJECT_NAME：作业所在的项目的名称。
CI_PROJECT_PATH：作业所在的项目的完整路径。
CI_PROJECT_DIR：作业所在的项目的根目录路径。
CI_RUNNER_ID：GitLab Runner的唯一标识符。
CI_RUNNER_DESCRIPTION：GitLab Runner的描述。
CI_REGISTRY：Docker注册表的URL。
CI_REGISTRY_IMAGE：Docker镜像的名称（不包含标签）。
CI_REGISTRY_USER：Docker注册表的用户名。
CI_REGISTRY_PASSWORD：Docker注册表的密码。