gitlab动态流水线

文章目录

- [1. 说明](#1. 说明)
- [2. 官方样例](#2. 官方样例)
- - [2.1 在作业中生成配置文件，保存为产物](#2.1 在作业中生成配置文件，保存为产物)
  - [2.2 将触发器作业配置为在生成配置文件的作业之后运行。](#2.2 将触发器作业配置为在生成配置文件的作业之后运行。)
- [3. 实战应用](#3. 实战应用)
- - [3.1 背景介绍](#3.1 背景介绍)
  - [3.2 项目介绍](#3.2 项目介绍)
  - [3.3 公共项目配置](#3.3 公共项目配置)
  - [3.4 测试项目配置](#3.4 测试项目配置)
  - [3.5 测试](#3.5 测试)
- [4. 总结](#4. 总结)

1. 说明

顾名思义，动态流水线就是一种动态生成的流水线，主要在于其具有强大的灵活性，可以在特殊的场景下基于我们的一个预期生成我们想要的流水线，从而来执行某个作业任务。

既然是动态生成的流水线，那肯定就需要额外的触发操作来运行流水线，这里我们可以通过trigger:include: artifact的方式，具体就是使用trigger关键字将 include: artifact 设置为生成的产物并通过 include: job 设置为创建产物的作业。

2. 官方样例

2.1 在作业中生成配置文件，保存为产物

generate-config:
  stage: build
  script: generate-ci-config > generated-config.yml
  artifacts:
    paths:
      - generated-config.yml

2.2 将触发器作业配置为在生成配置文件的作业之后运行。

child-pipeline:
  stage: test
  trigger:
    include:
      - artifact: generated-config.yml
        job: generate-config

在此示例中，GitLab 检索 generated-config.yml 并使用该文件中的 CI/CD 配置触发子流水线。

产物路径由GitLab 而非 runner 解析，因此该路径必须与运行GitLab 的操作系统的语法相匹配。如果GitLab 在 Linux 上运行但使用 Windows runner 进行测试，则触发作业的路径分隔符为 /。使用 Windows runner 的作业的其他 CI/CD 配置，如脚本，使用 \。

3. 实战应用

3.1 背景介绍

我们希望如果研发在提交代码的时候，如果commit message中有x86_64关键字，则创建一个Release_x86_64的job，如果commit message中有aarch64关键字，则创建一个Release_aarch64的job。
该案例使用了include的嵌套方式，也是另类的一种高级用法。

3.2 项目介绍

ci-test 是公共项目
- variables.yml 里面存放了群组级下的所有的常用的变量
- template.yml 里面是公共的job，里面也通过include 嵌套了variables.yml
ci-test-1 是测试项目

3.3 公共项目配置

gitlab-ci/vars/variables.yml

bash 复制代码

variables:
  DOCKER_VERSION: "Docker version 20.10.17, build 100c701"
  BUILD_TYPE: Release
  REGION: BJ
  TAG: dc

gitlab-ci/common_job/template.yml

bash 复制代码

##set default retry
default:
  retry: 
    max: 1
    when: runner_system_failure

##set image & gitlab-runner
.image@image:
  image:
    name: alpine:latest

.tags@tag:
  tags:
    - $TAG

##include variables
include:
  - project: "ops/ci-test"
    ref: dev
    file: "gitlab-ci/vars/variables.yml"

###set job
.build@build:
  script:
    - env
  extends: 
    - .image@image
    - .tags@tag
  rules:
    - when: always

3.4 测试项目配置

ci文件

stages:
  - test
  - build

include:
  - project: "ops/ci-test"
    ref: "dev"
    file:
      - "gitlab-ci/vars/variables.yml"
      
generate-config:
  stage: test
  image: alpine:latest
  script: 
    - env
    - chmod +x generate.sh
    - bash -x generate.sh
    - cat generated-config.yml
  artifacts:
    paths:
      - generated-config.yml
  before_script:
    - apk update
    - apk add bash

child-pipeline:
  stage: build
  trigger:
    include:
      - artifact: generated-config.yml
        job: generate-config

generate.sh

#!/bin/bash
echo $CI_COMMIT_MESSAGE

if [[ $CI_COMMIT_MESSAGE == *x86_64* ]];then
cat <<EOF > generated-config.yml
include:
  - project: "ops/ci-test"
    ref: "dev"
    file:
      - "gitlab-ci/common_job/template.yml"
stages:
  - generate_jobs
Release_x86_64:
  stage: generate_jobs
  image: alpine:latest
  extends:
    - .build@build
variables:
  DOCKER_VERSION: $DOCKER_VERSION
  BUILD_TYPE: $BUILD_TYPE
  PLATFORM: x86_64
  REGION: $REGION
EOF
elif [[ $CI_COMMIT_MESSAGE == *aarch64* ]]; then
cat <<EOF > generated-config.yml
include:
  - project: "ops/ci-test"
    ref: "dev"
    file:
      - "gitlab-ci/common_job/template.yml"
stages:
  - generate_jobs
Release_aarch64:
  stage: generate_jobs
  image: alpine:latest
  extends:
    - .build@build
variables:
  DOCKER_VERSION: $DOCKER_VERSION
  BUILD_TYPE: $BUILD_TYPE
  PLATFORM: aarch64
  REGION: $REGION
EOF
fi

3.5 测试

本地项目提交 - 提交commit包含x86_64

本地项目提交 - 提交commit包含aarch64

4. 总结

其实这个案例相对比较简单，主要想表达的一个思想是，在某个业务场景下，我们可以通过通过脚本动态的生成gitlab的流水线，从而达到我们想要的效果。

此外，这里也给大家推荐下gitlab官方项目的测试用例。