【基于 GitLab 的 CI/CD 实践】05、GitLab Pipeline 实践（下）

needs 并行阶段

制品下载

include

local 引入本地配置

file 引入其他项目配置

template 引入官方配置

remote 引入远程配置

extends 继承作业配置

extends & include

trigger 管道触发

多项目管道

父子管道

image

准备环境

services

environment

inherit

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-ref ref 下载最新成功的 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

可以允许引入外部 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 引入官方配置

只能使用官方提供的模板：lib/gitlab/ci/templates · master · GitLab.org / GitLab · GitLab

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

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

定义一个 aa.yml：

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

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。可以参考以下命令指定：（根据实际情况修改）

sudo gitlab-runner register \
  --non-interactive \
  --url "http://192.168.170.133/" \
  --registration-token "GR1348941sUxNyye1qD4HcTSW-TMw" \
  --executor "docker" \
  --docker-image alpine:latest \
  --description "docker-runner" \
  --maintenance-note "Free-form maintainer notes about this runner" \
  --tag-list "docker,aws" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

修改 docker-runner 拉取策略：

[root@run01 /home/gitlab-runner]# vim /etc/gitlab-runner/config.toml
······
[[runners]]
  name = "docker-runner"
  url = "http://192.168.170.133/"
  id = 3
  token = "F9JvXdw6AW4zoNsxRGaD"
  token_obtained_at = 2023-07-19T07:06:45Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    pull_policy = "if-not-present"    # 增加这一行即可
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

最后在 GitLab-Runner 机器上安装 Docker：【云原生 | Docker 基础篇】02、CentOS 7 安装 Docker 详细图文教程_centos7安装docker_Stars.Sky的博客-CSDN博客 image 语法：默认在注册 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:
    - docker
  script:
    - ls
    - sleep 2
    - echo "mvn clean "
    - sleep 10

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

services

工作期间运行的另一个 Docker 映像，并 link 到 image 关键字定义的 Docker 映像。这样，您就可以在构建期间访问服务映像.

服务映像可以运行任何应用程序，但是最常见的用例是运行数据库容器，例如 mysql 。与每次安装项目时都安装 mysql 相比，使用现有映像并将其作为附加容器运行更容易，更快捷。

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

environment

声明所部署的环境名称和访问地址，后续可以直接在 gitlab 环境变量中查看。非常方便。

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

上一篇文章：【基于 GitLab 的 CI/CD 实践】04、GitLab Pipeline 实践（中）_Stars.Sky的博客-CSDN博客