hugo-teek is loading...

2024-12-25 运维 +2 devops GitLab CI-CD语法实践 10388 字 49 分钟 -- 次

GitLAB-CI-CD

最后更新于: 2025-12-06 17:39:04

GitLab CI-CD

GitLabCI/CD简介

GitLabCI/CD是GitLab内置的持续集成与持续部署系统

开源： CI/CD是开源GitLab社区版和专有GitLab企业版的一部分。(极狐)
易于学习：官方具有详细的学习操作文档。
无缝集成： CI/CD是GitLab的一部分，支持从计划到部署,具有出色的用户体验。 (例如：做一些基于版本控制系统的提交流水线、合并流水线，是很方便的！)
可扩展：可以根据需要添加任意数量的构建节点。
更快的结果：每个构建可以拆分为多个作业，这些作业可以在多台计算机上并行运行。
针对交付进行了优化：多个阶段，手动部署，环境和变量。

tstmp_20230425213814

针对交付进行了优化：多个阶段，手动部署，环境和变量。

jenkins里，你想要获取git分支、git提交用户的话，我们都需要先去抓收据，去采集数据，进行一个过滤，再拿到；

但在gitlab里，使用gitlab ci时，里面就有现成的环境变量，我们直接使用就好，所以这一点，还是有很大的优势的。这个文档是大家在开发流水线时必须依赖的一个文档，使用时要注意下这里的版本！

https://docs.gitlab.com/14.9/ee/ci/variables/predefined_variables.html

gitlab ci/cd官方文档

https://docs.gitlab.com/14.9/ee/ci/

常用变量参考文档：

https://docs.gitlab.com/14.9/ee/ci/variables/predefined_variables.html

Pipeline

在每个项目中，使用名为的YAML文件配置GitLab CI/CD流水线。

tstmp_20230425214236

Stages

一条流水线可以包含若干个阶段，一个阶段可以包含若干个作业。

tstmp_20230425214313

Job

作业是具体要执行的任务，命令脚本语句的集合；

tstmp_20230425214327

Runner

Runner是每个作业的执行节点；每个作业可以根据标签选择不同的构建节点；

tstmp_20230425214357

GitLabRunner安装部署

见独立md文件。

开发第一条Pipeline

1. gitlab-ci.yml

如何开启GitLabCI/CD? 首先要将代码存储到GitLab，然后在代码库的（默认根目录）添加一个.gitlab-ci.yml文件。该文件中定义了流水线的阶段和运行步骤。

根据不同的场景，可以自定义流水线定义文件的位置。

(默认)存储到项目根目录： /.gitlab-ci.yml

为项目中添加.gitlab-ci.yml文件，表示启动的CI/CD。默认提交动作会自动运行该.gitlab-ci.yml中定义的作业。

来到gitlab项目里，创建一个.gitlab-ci.yml文件

tstmp_20230426123643

1 填写当前创建的文件的名称.gitlab-ci.yml;
2 选择文件的类型；
3 选择一个项目模板；（这里我们先选择一个bash类型）

进行提交，默认就会自动跑流水线了：

但是，此时流水线状态为pending状态，这是为什么呢？

根据报错提示，可以知道是因为.gitlab-ci.yml文件里没指定runner

我们这里先重新写下代码

因此，一般情况下，我们再写流水线代码时，一般需要给每个阶段指定tags：

注意：这里的每个阶段都要添加这个tags才行！

改好后，提交，并观察流水线运行状态：

此时，流水线运行状态就正常了。

我们这里想手动来触发下流水线，观察下test阶段2个作业，为什么这2个作业不是并行运行的呢？

是因为我们的gitlab-runner的配置文件里需要修改下并行选项参数：

1[root@Devops6 ~]#vim  /etc/gitlab-runner/config.toml
2将concurrent = 1
3改为
4concurrent = 10

配置完后，默认生效的。

我们再来运行一次流水线，观察下现象

可以看到，这里是并行运行作业的了，符合预期。

2. 流水线页面

tstmp_20230427073303

1 清除runner的缓存；
2 进行CI文件语法校验；
3 手动触发运行流水线；
4 流水的步骤，可以查看各个阶段的运行日志；

3. Pipeline编辑器

tstmp_20230427073424

Pipeline开发工具与设置

1.Pipeline开发工具

可视化编辑器

变更.gitlab-ci.yml文件后，可以通过Visualize对CI文件中的定义进行可视化；

tstmp_20230427075340

语法检测校验

通过Lint可以检测当前CI文件是否存在语法错误；若存在语法错误可以根据提示进行修正；

tstmp_20230427075408

作业运行日志

一条流水线包含很多个作业，每个作业的运行日志可以在Jobs界面看到。

tstmp_20230427075439

Pipeline环境变量

预定义变量信息：https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

代码类

CI_COMMIT_AUTHOR 提交人
CI_COMMIT_BRANCH 提交分支
CI_COMMIT_MESSAGE
CI_COMMIT_REF_NAME
CI_COMMIT_SHORT_SHA

作业类：

CI_JOB_ID
CI_JOB_NAME
CI_JOB_STAGE
CI_JOB_URL

流水线类：

CI_PIPELINE_ID
CI_PIPELINE_SOURCE
CI_PIPELINE_TRIGGERED
CI_PIPELINE_URL

2.Pipeline设置

General pipelines

管道权限、取消冗余管道、跳过历史部署作业；

为项目自定义ci文件

修改名称：gitlab-ci-cd.yml
自定义路径：../ci/xx/xx/.yml
也是可以这种raw格式的：（但是切记，一定是可公开访问的路径，不能到凭据信息）

http://172.29.9.101:8076/devops6/devops-demo-service/-/raw/main/.gitlab-ci.yml

为项目设置流水线状态标志

支持Markdown、HTML、AsciiDoc格式。

tstmp_20230427075903

tstmp_20230427075918

==💘 实战：为项目设置流水线状态标志-2023.5.8(测试成功)==

实验环境

1gitlab/gitlab-ce:15.0.3-ce.0

实验软件（无）
在项目代码的README.md文件里添加如下部分代码

1[![pipeline status](http://172.29.9.101:8076/devops6/devops-demo-service/badges/main/pipeline.svg)](http://172.29.9.101:8076/devops6/devops-demo-service/-/commits/main)

此部分代码位置：gitlab项目-Settings-CI/CD-Gernral Pipelines-Pipeline Status

本次在main分支的README.md文件下添加如上部分代码

提交代码后，触发流水线，观察结果

符合预期。😘

设置管道(pipeline)预览权限

可以来到项目>Project information>Members：给这个项目里增加成员

Guest和非项目成员无法，看到管道中作业的日志和管道所生成的制品；

开启公共的管道访问：

公共项目，每个人都可以访问。
内部项目，对于除外部用户之外的所有登录用户。
私人项目，所有项目成员（Guest 或更高级别）。

可以来到项目>Settings>CI/CD>Genernal pipelines：配置管道权限！

Pipeline核心语法

gitlab-ci语法：

https://docs.gitlab.com/ee/ci/yaml/

stages 阶段控制

.pre阶段的作业总是在流水线开始时执行；
.post阶段的作业总是在流水线结束时执行；

CI代码：

 1stages:
 2  - build
 3  - test
 4  - deploy 
 5
 6job0:
 7  tags:
 8    - go
 9  stage: .pre
10  script:
11    - echo " init"
12
13job1:
14  tags:
15    - go
16  stage: build
17  script:
18    - echo "build"
19
20job2-1:
21  tags:
22    - mvn
23  stage: test
24  script:
25    - echo "test"
26    - sleep 10
27
28job2-2:
29  tags:
30    - mvn
31  stage: test
32  script:
33    - echo "test"
34
35job3:
36  tags:
37    - go
38  stage: deploy
39  script:
40    - echo "deploy"
41
42job10:
43  tags:
44    - go
45  stage: .post
46  script:
47    - echo "end"

代码直接写在gitlab的CI/CD的editor里：

这里我们先修改下runner上的标签

运行

如果两个或者多个作业，指向同一个阶段名称，则该阶段下的所有作业都并行运行；如果不能并行运行，需要检查runner的配置文件中的concurrent值，要大于1。

variables 环境变量

变量可以分为全局变量和局部变量；全局变量是整个流水线可以用的，局部变量是仅在作业中生效的；

CI代码

 1stages:
 2  - build
 3
 4variables:
 5  BUILD_TOOLS: 
 6    value: "mvn"
 7    description: "choice build tools"   #描述信息，注释不能用//，只能用#号。
 8  RUNNER_TAG: "go"
 9
10
11job1:
12  tags:
13    - "${RUNNER_TAG}"
14  stage: build
15  variables:
16    BUILD_TOOLS: "gradle"
17  script:
18    - echo "${BUILD_TOOLS}"

运行

job 作业默认配置

定义一个作业的时候，一般定义哪些关键字呢？作业在哪个runner运行？作业属于流水线中的哪个阶段？这个作业要做什么？

CI代码

 1stages:
 2  - build
 3
 4variables:
 5  RUNNER_TAG: "go"
 6
 7before_script:
 8  - echo "pipeline before script"
 9after_script:
10  - echo "pipeline after script"
11
12job1:
13  tags:
14    - ${RUNNER_TAG}
15  stage: build
16  before_script:
17    - echo "before script...."
18  script:
19    - echo "mvn package"
20  after_script:
21    - echo "after script..."
22
23job2:
24  tags:
25    - ${RUNNER_TAG}
26  stage: build
27  script: 
28    - echo "build"

参数解析：

语法关键字	作用	备注
variables	定义作业中的环境变量；
tags	根据标签选择运行作业的构建节点；	多个标签，则匹配具有所有标签的构建节点；GitLab14.1版本后，标签的值可以使用变量；GitLab14.3版本后，标签数量必须小于50；
stage	指定当前作业所属的阶段名称；
before_script	作业在运行前执行的Shell命令行；
script	作业在运行中执行的Shell命令行；	每个作业至少要包含一个script；
after_script	作业在运行后执行的Shell命令行；

运行

需要注意：如果before_script和after_script定义在pipeline里，则每个作业里都会运行这2个脚本；如果是定义在某个job里，则只会在其job里运行！

job 作业运行控制

语法关键字	作用	备注
allow_failure	控制作业状态，是否允许作业失败，默认值为false 。启用后，如果作业运行失败，该作业将在用户界面中显示橙色警告。	管道将认为作业成功/通过，不会被阻塞。假设所有其他作业均成功，则该作业的阶段及其管道将显示相同的橙色警告。但是，关联的提交将被标记为"通过"，而不会发出警告。
when	根据状态控制作业运行, 当前面作业成功或者失败时运行。	on_success 前面阶段成功时执行(默认值);on_failure 前面阶段失败时执行；always 总是执行；manual 手动执行；delayed 延迟执行；start_in'5'5 seconds30 minutes1 day1 weeknever 永不执行；
retry	作业重新运行，遇到错误重新运行的次数。	值为整数等于或大于0，但小于或等于2异常分类 (一般就是3次)
timeout	作业运行超时时间；
rules	根据特定的变量或文件变更来控制作业运行；	ifchangesexists
needs	作业依赖控制；	needs: [“作业名称”]
parallel	生成多个作业，并行运行	parallel:5值 2-50之间

parallel 并行运行

代码

 1stages:
 2  - build
 3
 4variables:
 5  RUNNER_TAG: "go"
 6
 7job1:
 8  tags:
 9    - ${RUNNER_TAG}
10  stage: build
11  parallel: 5
12  script:
13    - echo "mvn package"

模拟做压测。

运行

needs 作业关联运行

CI代码

needs 指定要依赖的作业名称

 1stages:
 2  - build
 3  - test
 4
 5variables:
 6  RUNNER_TAG: "go"
 7
 8job1:
 9  tags:
10    - ${RUNNER_TAG}
11  stage: build
12  script:
13    - echo "mvn package"
14    - sleep 10
15
16job2:
17  tags:
18    - ${RUNNER_TAG}
19  stage: build
20  script: 
21    - echo "build"
22
23
24job3:
25  tags:
26    - ${RUNNER_TAG}
27  stage: test
28  script:
29    - echo "mvn package"
30
31job4:
32  tags:
33    - ${RUNNER_TAG}
34  stage: test
35  needs: ["job2"]
36  script:
37    - echo "mvn package"

运行

tstmp_20230510204814

tstmp_20230510204829

rules根据变量/文件控制

根据条件（变量）判断： IF

用法：

 1定义变量条件;
 2
 3运算符：
 4● =
 5● !=
 6● =~
 7
 8条件链接符：
 9● &&
10● ||

CI代码：

 1variables:
 2  DOMAIN: example.com
 3
 4codescan:
 5  stage: build
 6  tags:
 7    - build
 8  rules:
 9    - if: '$DOMAIN == "example.com"'
10      when: manual
11    - when: on_success
12  script:
13    - echo "codescan"
14    - sleep 5;

运行：

根据文件判断: `changes` `exists`

changes

文件变更时条件为真；

示例：代码提交后，当Dockerfile文件发生变更则条件为真。即手动执行此作业。

注意：非Push相关动作，此条件永远为真。

CI代码：

 1citest1:
 2  tags:
 3    - build
 4  stage: test
 5  rules:
 6    - changes:
 7        - Dockerfile
 8      when: manual
 9    - when: never
10  script:
11    - echo "Do a test here"
12    - echo "For example run a test suite"

运行：

直接运行次作业时，肯定是不会运行流水线的，因此此时是没有Dockerfile文件的。

我们来创建一个Dockerfile文件，再次运行流水线，并观察现象：

allow_failure

允许作业在不停止管道的情况下失败；

CI代码：

 1stages:
 2  - test
 3
 4citest1:
 5  tags:
 6    - build
 7  stage: test
 8  allow_failure: true
 9  script:
10    - lsl -l
11    - echo "Do a test here"
12
13
14citest2:
15  tags:
16    - build
17  stage: test
18  script:
19    - ls -l
20    - echo "Do a test here"
21

运行：

variables

重新定义变量的值；

示例：如果当前的分支是主干分支main，则重新定义ENV_TYPE的值为prod。

注意：只影响局部作业内的变量，不会影响全局变量。

CI代码：

 1variables:
 2  ENV_TYPE: "dev"
 3  
 4cddeploy:
 5  tags:
 6    - build
 7  stage: deploy
 8  rules:
 9    - if: $CI_COMMIT_REF_NAME == "main"
10      variables:
11        ENV_TYPE: "prod"
12  script:
13    - echo "Deploy env ${ENV_TYPE}"

运行：

🍀 某一类文件写法：

when

同when语法的运行方式；

这里的when是写在rules里面的，也可以写在外面的。

rules代码汇总：

 1stages:
 2  - build
 3  - test
 4
 5variables:
 6  RUNNER_TAG: "go"
 7  SKIP_BUILD: "true"
 8
 9
10job1:
11  tags:
12    - ${RUNNER_TAG}
13  stage: build
14  rules:
15    - if: '$SKIP_BUILD == "true"'   # 此时job1 不会被运行
16      when: never
17    - when: always
18  before_script:
19    - echo "before script...."
20  script:
21    - echo "mvn package"
22  after_script:
23    - echo "after script..."
24
25
26job2:
27  tags:
28    - ${RUNNER_TAG}
29  stage: test
30  rules:
31    - changes:
32      - README.md     # 提交时仅该文件存在变更时才会触发
33      when: always
34    - when: never
35  script:
36    - echo "test"
37
38job3:
39  tags:
40    - ${RUNNER_TAG}
41  stage: test
42  rules:
43    - exists:
44        - Dockerfile  #只要项目中存在该文件就会运行，提交存在也算。
45      when: manual
46    - when: never
47  script:
48    - echo "test"
49
50job4:
51  tags:
52    - ${RUNNER_TAG}
53  stage: test
54  script:
55    - echo "test"

运行：

when 状态控制和运行方式

根据上游作业的状态决定
- 当前作业是否运行？
- 运行的方式？（手动/自动/定时）

CI代码：

 1stages:
 2  - build
 3  - test
 4  - deploy
 5
 6variables:
 7  RUNNER_TAG: "go"
 8
 9job1:
10  tags:
11    - ${RUNNER_TAG}
12  stage: build
13  before_script:
14    - echo "before script...."
15  script:
16    - echo "mvn package"
17  after_script:
18    - echo "after script..."
19
20
21
22job2:
23  tags:
24    - ${RUNNER_TAG}
25  stage: test
26  when: on_success
27  script: 
28    - echo "build"
29
30
31job3:
32  tags:
33    - ${RUNNER_TAG}
34  stage: test
35  when: on_failure
36  script: 
37    - echo "build"
38
39job4:
40  tags:
41    - ${RUNNER_TAG}
42  stage: deploy
43  when: manual
44  script: 
45    - echo "build"

运行：

when: delay

 1test1:
 2  tags:
 3    - ${RUNNER_TAG} 
 4  stage: test
 5  script:
 6    - echo "Do a test here"
 7    - echo "For example run a test suite"
 8    - sleep 3
 9  when: delay
10  start_in: '5'

timeout作业运行超时时间

1build:
2  script: build.sh
3  timeout: 3 hours 30 minutes
4
5test:
6  script: rspec
7  timeout: 3h 30m

retry 作业失败后重试次数

CI代码：

 1stages:
 2  - build
 3  - test
 4
 5variables:
 6  RUNNER_TAG: "go"
 7
 8job1:
 9  tags:
10    - ${RUNNER_TAG}
11  stage: build
12  retry: 2
13  before_script:
14    - echo "before script...."
15  script:
16    - echo "mvn package"
17    - mvs
18  after_script:
19    - echo "after script..."
20
21job2:
22  tags:
23    - ${RUNNER_TAG}
24  stage: test
25  script: 
26    - echo "build"

运行：

根据特定的错误匹配：

 1always ：在发生任何故障时重试（默认）。
 2unknown_failure ：当失败原因未知时。
 3script_failure ：脚本失败时重试。
 4api_failure ：API失败重试。
 5stuck_or_timeout_failure ：作业卡住或超时时。
 6runner_system_failure ：构建节点的系统发生故障。
 7missing_dependency_failure: 依赖丢失。
 8runner_unsupported ：Runner不受支持。
 9stale_schedule ：无法执行延迟的作业。
10job_execution_timeout：作业运行超时。
11archived_failure ：作业已存档且无法运行。
12unmet_prerequisites ：作业未能完成先决条件任务。
13scheduler_failure ：调度失败。
14data_integrity_failure ：结构完整性问题。
15
16
17####
18max ：最大重试次数  when ：重试失败的错误类型
19
20stages:
21  - build
22  - test
23
24variables:
25  RUNNER_TAG: "go"
26
27job1:
28  tags:
29    - ${RUNNER_TAG}
30  stage: build
31  retry: 2  # 不管任何错误，都重试2次
32  before_script:
33    - echo "before script...."
34  script:
35    - echo "mvn package"
36    - mvs  # 命令错误
37  after_script:
38    - echo "after script..."
39
40job2:
41  tags:
42    - ${RUNNER_TAG}
43  stage: test
44  when: on_failure  # 为了让这个作业运行所以添加的，不然前面作业失败这个作业就不运行了。
45  script: 
46    - echo "build"
47    - aaa   # 命令错误
48  retry:
49    max: 2
50    #when: api_failure
51    when: script_failure   # 定义脚本错误：  正常会retry两次

运行：

allow_failure 允许作业失败

CI代码：

 1stages:
 2  - build
 3  - test
 4
 5variables:
 6  RUNNER_TAG: "go"
 7
 8job1:
 9  tags:
10    - ${RUNNER_TAG}
11  stage: build
12  allow_failure: true
13  retry: 2
14  before_script:
15    - echo "before script...."
16  script:
17    - echo "mvn package"
18    - mvs
19  after_script:
20    - echo "after script..."
21
22job2:
23  tags:
24    - ${RUNNER_TAG}
25  stage: test
26  script: 
27    - echo "build"

运行：

Pipeline运行控制

1.workflow 控制流水线

控制管道是否创建和运行。根据条件（变量）判断： IF

if 定义变量条件;
variables 重新定义变量的值；
when
- always
- never

命令	备注
if: ‘$CI_PIPELINE_SOURCE == “merge_request_event”’	合并请求时运行流水线；
if: ‘$CI_PIPELINE_SOURCE == “push”’	提交代码运行流水线；

预定义变量

https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

🍀 demo

CI代码：

 1variables:
 2  SKIP_RUN: "true"
 3  RUNNER_TAG: "go"
 4
 5workflow:
 6  rules:
 7    - if: $CI_PIPELINE_SOURCE == "push"
 8      when: never
 9      
10stages:
11  - build
12
13job2:
14  tags:
15    - ${RUNNER_TAG}
16  stage: build
17  script: 
18    - echo "build"

运行：

运行后，是没看见触发流水线的。

🍀 demo

CI代码：

 1variables:
 2  SKIP_RUN: "true"
 3  RUNNER_TAG: "go"
 4
 5workflow:
 6  rules:
 7    - if: $CI_PIPELINE_SOURCE == "push"
 8      when: never
 9    - if: $CI_PIPELINE_SOURCE == "web"
10      when: never
11      
12stages:
13  - build
14
15job2:
16  tags:
17    - ${RUNNER_TAG}
18  stage: build
19  script: 
20    - echo "build"

运行：

可以看到，这里在web触发时，依然报错了：……

2.Git 选项跳过流水线

提交信息中添加关键字 [ci skip] 或者 [skip ci]；
Git 2.10 更高版本，可以通过以下配置设置CI/CD；

1## 跳过
2git push -o ci.skip
3
4## 传递变量
5git push -o ci.variable="MAX_RETRIES=10" -o ci.variable="MAX_TIME=600"

🍀 demo

这里改变下项目里readme文件内容，进行提交，commit message信息里写上[ci skip]，再次观察是否会触发提交流水线（默认是提交一次就会触发一次流水线的）？

可以看到，这里跳过了流水线的触发。

3.trigger 触发下游管道

触发项目管道
触发子管道

strategy：默认情况下，一旦创建了下游管道，trigger作业就会以success状态完成。要强制等待下游管道完成，使用 strategy: depend。

触发项目管道：（不要自己触发自己，这样就进入到一个环里面了。）

1triggers:
2  stage: deploy
3  trigger:
4    project: devops/devops-maven-service
5    branch: main
6    strategy: depend    ## 状态同步

触发子管道：

 1stages:
 2  - deploy
 3
 4trigger-cd-pipeline:   
 5  stage: deploy
 6  trigger:
 7    include: ci/stages.yml  ## 触发当前项目的子流水线
 8
 9
10trigger-project-pipeline:
11  stage: deploy
12  trigger:
13    include:
14    - project: "devops/devops05-app-service"   ## 触发其它项目的子流水线
15      ref: "main"
16      file: "ci/stages.yml"

tstmp_20230513081626

测试过程：

创建一个项目

devops6-gitlabci-demo

在新项目里创建一个.gitllabci.yml文件：

 1stages:
 2  - build
 3
 4before_script:
 5  - echo "Before script section"
 6  - echo "For example you might run an update here or install a build dependency"
 7  - echo "Or perhaps you might print out some debugging details"
 8
 9after_script:
10  - echo "After script section"
11  - echo "For example you might do some cleanup here"
12
13build1:
14  tags:
15    - go
16  stage: build
17  script:
18    - sleep 20
19    - echo "Do your build here"

先来测试下触发项目管道

1stages:
2  - deploy
3
4triggers:
5  stage: deploy
6  trigger:
7    project: devops6/devops6-gitlabci-demo
8    branch: main
9    strategy: depend    ## 状态同步

提交代码并观察现象：

可以看到，此时成功触发了其他项目。

再来测试下 trigger触发当前项目的子流水线

在当前项目devops-demo-service里创建.ci/ci.yaml文件：

 1stages:
 2  - build
 3  - test
 4
 5build01:
 6  stage: build
 7  tags:
 8    - go
 9  script:
10    - echo "build"
11
12
13test01:
14  stage: test
15  tags:
16    - go
17  script:
18    - echo "test"

提交后，默认就会触发流水线的运行：

此时，有这个需求：改了目录里面的内容，就不让他构建，该怎么写？

CI代码：

 1stages:
 2  - deploy
 3
 4workflow:
 5  rules:
 6    - changes:
 7        - .ci/*
 8      when: never
 9    - when: always
10
11triggers:
12  stage: deploy
13  trigger:
14    project: devops6/devops6-gitlabci-demo
15    branch: main
16    strategy: depend    ## 状态同步

此时，提交后，我们再次修改.ci/ci.yaml内容，再次观察是否会触发流水线？

 1stages:
 2  - build
 3  - test
 4
 5build01:
 6  stage: build
 7  tags:
 8    - go
 9  script:
10    - echo "build"
11
12
13test01:
14  stage: test
15  tags:
16    - go
17  script:
18    - echo "test"
19
20test02:
21  stage: test
22  tags:
23    - go
24  script:
25    - echo "test"

提交并观察：

可以看到，此时就不会触发流水线了。

我们继续看下trigger如何触发当前项目的子流水线

CI代码：

 1stages:
 2  - deploy
 3
 4workflow:
 5  rules:
 6    - changes:
 7        - .ci/*
 8      when: never
 9    - when: always
10
11triggers:
12  stage: deploy
13  trigger:
14    project: devops6/devops6-gitlabci-demo
15    branch: main
16    strategy: depend    ## 状态同步
17
18triggers2:
19  stage: deploy
20  trigger:
21    include: .ci/ci.yaml

提交：

此时，已经成功触发了当前项目的子流水线。

我们再来看看如何触发其他项目的子流水线？

在之前新创建的devops6-gitlabci-demo项目里创建.ci/ci.yaml：

 1stages:
 2  - build
 3  - test
 4
 5build01:
 6  stage: build
 7  tags:
 8    - go
 9  script:
10    - echo "build"
11
12
13test01:
14  stage: test
15  tags:
16    - go
17  script:
18    - echo "test"
19
20test02:
21  stage: test
22  tags:
23    - go
24  script:
25    - echo "test"

提交。然后在devops-demo-service项目的.gitlab-ci.yml里编写CI代码：

 1stages:
 2  - deploy
 3
 4workflow:
 5  rules:
 6    - changes:
 7        - .ci/*
 8      when: never
 9    - when: always
10
11triggers:
12  stage: deploy
13  trigger:
14    project: devops6/devops6-gitlabci-demo
15    branch: main
16    strategy: depend    ## 状态同步
17
18triggers2:
19  stage: deploy
20  trigger:
21    include: .ci/ci.yaml
22
23trigger-project-pipeline:
24  stage: deploy
25  trigger:
26    include:
27    - project: "devops6/devops6-gitlabci-demo"   ## 项目名称
28      ref: "main"
29      file: ".ci/ci.yaml"

提交并观察现象：

符合预期。

4.API触发Pipeline

创建一个认证token：

使用API触发

使用curl命令进行测试：

1curl -X POST \
2     -F token=156d70fce2d6afca6d0b21c6624b85 \
3     -F ref=main \
4     http://172.29.9.101:8076/api/v4/projects/2/trigger/pipeline

这里的2是项目id：

触发后，报如下提示：

看是被workflow规则过滤了：

这里再改下CI代码：

提交后，再次在命令行进行触发：

这里还是提示被workflow规则过滤了。

再次修改下CI代码：

 1stages:
 2  - deploy
 3
 4workflow:
 5  rules:
 6    - if: $CI_PIPELINE_SOURCE == "trigger"
 7      when: always          
 8    - changes:
 9        - .ci/*
10      when: never
11    - when: always
12
13triggers:
14  stage: deploy
15  trigger:
16    project: devops6/devops6-gitlabci-demo
17    branch: main
18    strategy: depend    ## 状态同步
19
20triggers2:
21  stage: deploy
22  trigger:
23    include: .ci/ci.yaml
24
25trigger-project-pipeline:
26  stage: deploy
27  trigger:
28    include:
29    - project: "devops6/devops6-gitlabci-demo"   ## 项目名称
30      ref: "main"
31      file: ".ci/ci.yaml"

提交后，再次在命令行触发，观察现象：

因此，要特别注意下，这个workflow下的规则匹配。（这里把它写在最上面就可以正常触发了，但是写在changes下面，就不能正常触发的）

使用postman测试

tstmp_20230513163849

gitlabci作业中触发

1script:
2  - "curl -X POST -F token=TOKEN -F ref=REF_NAME http://172.29.9.101:8076/api/v4/projects/2/trigger/pipeline"

优化：将token以变量的方式存储到项目中。

 1stages:         
 2  - build
 3
 4build-job: 
 5  tags:
 6    - build     
 7  stage: build
 8  script:
 9    - "curl -X POST -F token=${CITOKEN} -F ref=main  http://172.29.9.101:8076/api/v4/projects/2/trigger/pipeline"
10    - echo "Compile complete."
11    - sleep 1

触发并传递参数

1     curl -X POST \
2     -F token=156d70fce2d6afca6d0b21c6624b85 \
3     -F ref=main \
4     -F "variables[BUILD_TOOL]=mavenandmaven" \
5     http://172.29.9.101:8076/api/v4/projects/2/trigger/pipeline

1ciTriggerTest:
2  tags:
3    - build
4  stage: build
5  script:
6    - echo ${BUILD_TOOL}

PipelineTemplate实践

https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates

extends

extends可以指定多个模板，相同的参数最后模板会覆盖前面的。例如：下面两个模板中，继承关系是：

继承 .test1 （此时rspec的变量NAME的值为gitlab）
继承 .test2 （此时rspec的变量NAME的值为gitlabCI , 覆盖了.test1中的值）

 1.test1:
 2  variables:
 3    NAME: "gitlab"
 4  tags:
 5    - build
 6  stage: test
 7  rules:
 8    - if: $CI_COMMIT_BRANCH == "main"
 9  script: echo "mvn test"
10
11.test2:
12  variables:
13    NAME: "gitlabCI"
14  tags:
15    - build01
16  stage: test
17  
18rspec:
19  extends: 
20    - .test1
21    - .test2
22  script: echo " DevOps"
23
24      
25      
26      
27###### 结果
28
29rspec:
30  variables:
31    NAME: "gitlabCI"
32  tags:
33    - build01
34  stage: test
35  rules:
36    - if: $CI_COMMIT_BRANCH == "main"
37  script: echo " DevOps"

include

include用于在CI/CD 配置中引入外部 YAML 文件。可以将一个长.gitlab-ci.yml文件分解为多个文件以提高可读性，或减少同一配置在多个地方的重复。

local 导入当前仓库中的文件；
file 导入当前项目或其他项目库中的文件；
remote 导入一个远程的文件（例如：http://xxx.yaml）
template 导入GitLab官方提供的模板文件；

 1## 本地仓库文件
 2include:
 3  - local: '/templates/.gitlab-ci-java.yml'
 4 
 5## 其他仓库文件
 6include:
 7  - project: 'devops/my-project'
 8    ref: main
 9    file: 
10      - '/templates/.gitlab-ci-java.yml'
11      - '/templates/.tests.yml'
12    
13## 远程文件
14include:
15  - remote: 'https://192.168.1.200//-/raw/main/.gitlab-ci.yml'

🍀 测试

Extend：继承模板

Include：引入模板

创建新项目 gitlab-temp-repo

定义2个模板

创建CI/java-ci.yaml文件：

 1.test1:
 2  variables:
 3    NAME: "gitlab"
 4  tags:
 5    - build
 6  stage: test
 7  rules:
 8    - if: $CI_COMMIT_BRANCH == "main"
 9  script: echo "mvn test"
10
11.test2:
12  variables:
13    NAME: "gitlabCI"
14  tags:
15    - build02
16  stage: test
17  script: echo "mvn test"

在devops-demo-service项目编辑CI文件

 1include:
 2  - project: 'devops6/gitlab-temp-repo'
 3    ref: main
 4    file: 
 5      - '/CI/java-ci.yaml'
 6
 7test1:
 8  extends:
 9    - .test1
10
11test2:
12  tags:
13    - build
14  extends:
15    - .test2

运行

能够做成每个项目一个template就很不错了。

综合实例：

将模板文件，放到单独的一个仓库中；

ci.yml

 1.build:
 2  tags:
 3    - build
 4  stage: build
 5  variables:
 6    BUILD_TOOL: "maven3"
 7    BUILD_SHELL: "mvn clean package"
 8  script:
 9    - "${BUILD_SHELL}"
10
11.test:
12  tags:
13    - "linux"
14  stage: test
15  variables:
16    TEST_SHELL: "mvn test"
17  script:
18    - "${TEST_SHELL}"

.gitlab-ci.yml

 1workflow:
 2  rules:
 3    - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"  # 40个零 创建分支或者tag
 4      when: never
 5
 6include:
 7  - project: 'devops/devops-ci-lib'   ## 引入ci.yml模板
 8    ref: main
 9    file: '/CI/ci.yml'
10
11variables:
12  GIT_CHECKOUT: "false"
13  RUNNER_TAG: "mvn"
14  BUILD_SHELL: "mvn clean package -DskipTests"
15  TEST_SHELL: "mvn test"
16
17stages:
18  - build 
19  - test
20
21# 下载代码
22checkout:
23  tags:
24    - ${RUNNER_TAG}
25  stage: .pre 
26  variables:
27    GIT_CHECKOUT: "true"
28  script:
29    - echo "GetCode..."
30
31# maven构建
32build:
33  tags:
34    - ${RUNNER_TAG}
35  extends: .build  ##重用build作业
36
37# maven test
38test:
39  tags:
40    - ${RUNNER_TAG}
41  extends: .test

💘 实践：练习Pipeline模板库(测试成功)-2022.5.6(这个有点难度)

🍀 老师文档

创建一个新的项目 “devops4/devops4-devops-service” (模板库);
为项目添加一个CI模板文件（ci/ci.yml）；（参考pipeline.yml）
添加cicd.yml 文件， pipeline， include导入模板库中的ci/ci.yml

ci/ci.yml： ‘devops4/devops4-devops-service 模板库

1.build:
2  variables:
3    SHELL: "mvn clean build"
4  tags:
5    - build
6  stage: build
7  script: echo "${SHELL}"

cicd.yml

 1### 导入仓库文件
 2include:
 3  - project: 'devops4/devops4-devops-service'
 4    ref: main
 5    file: 
 6      - '/ci/ci.yml'
 7variables:
 8  BUILD_SHELL: "mvn build"
 9stages:
10  - build
11  
12### 继承模板
13build:
14  extends: 
15    - .build
16  variables:
17    SHELL: $BUILD_SHELL

远程CI文件配置:

http://192.168.1.200/devops4/devops4-devops-service/-/raw/main/cicd.yml

🍀 自己测试过程：

创建模板库devops4-devops-service

创建如下相关文件：

ci/ci.yml

1.build:
2  variables:
3    SHELL: "mvn clean build"
4  tags:
5    - build
6  stage: build
7  script: echo "${SHELL}"

cicd.yml

 1### 导入仓库文件
 2include:
 3  - project: 'devops4/devops4-devops-service'
 4    ref: main
 5    file: 
 6      - '/ci/ci.yml'
 7      
 8variables:
 9  BUILD_SHELL: "mvn build"
10stages:
11  - build
12  
13### 继承模板
14build:
15  extends: 
16    - .build
17  variables:
18    SHELL: $BUILD_SHELL

写完后提交。

获取cicd.yml文件的路径：

http://172.29.9.101/devops4/devops4-devops-service/-/raw/main/cicd.yml

来到另一个项目里devops4-monrepo-service

在项目>Settings>CI/CD>Gerneral pipelines里把刚才拷贝的那个链接填在这里，保存：

然后，直接运行这个流水线，观察效果：

符合预期，实验结束。

提交阶段流水线

因为GitLabCI与GitLab版本控制系统深度集成，所以不需要配置触发器。

默认已经支持了提交代码、合并代码触发流水线的运行；
默认流水线运行后会自动的下载本项目代码；(每个job会下载项目代码)

流水线优化

1.过滤新建分支和tag的触发

1workflow:
2  rules:
3    - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
4      when: never

🍀 测试过程如下：

先来测试下，gitlabci里新建分支是否会触发流水线的运行？

本次在devops4-commit-service项目里测试：

新创建分支feature-dev-03：

可以看到，新建分支操作是会触发流水线运行的：

编写pipeline代码，通过CI_COMMIT_BEFORE_SHA来过滤新建分支和tag的触发：

编写之前可以来看下gitlabci官网预定义的一些变量：

 1workflow:
 2  rules:
 3    - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
 4      when: never
 5    - when: always
 6
 7stages:
 8  - build 
 9  - test
10  - deploy
11before_script:
12  - echo "Before script section"
13  - echo "For example you might run an update here or install a build dependency"
14  - echo "Or perhaps you might print out some debugging details"
15
16after_script:
17  - echo "After script section"
18  - echo "For example you might do some cleanup here"
19
20build:
21  stage: build
22  script:
23    - echo "Do your build here"
24
25test:
26  stage: test
27  script:
28    - echo "Do another parallel test here"
29    - echo "For example run a lint test"
30
31build-job:   
32  stage: build
33  script:
34    - "curl -X POST -F token=${CITOKEN} -F ref=main http://172.29.9.101/api/v4/projects/2/trigger/pipeline"
35    - echo "Compile complete."
36    - sleep 1
37
38
39deploy:
40  stage: deploy
41  script:
42    - echo "Do your deploy here"

验证

此时，再新建一个分支，看是否会触发流水线的运行

可以发现，此时新建分支不会触发流水线的运行了，符合预期：

2.解决job运行重新下载代码

制品需要通过分布式缓存或者通过语法提前保存。
指的是，不同的runner节点。

通过下面的CI作业，观察第二个作业是否可以拿到第一个作业的文件；

 1variables:
 2  ENV_TYPE: "dev"
 3
 4cibuild:
 5  tags:
 6    - build
 7  stage: build
 8  script:
 9    - ls -l 
10    - echo 123 >test.yaml 
11    - ls -l 
12
13citest1:
14  tags:
15    - build
16  stage: test
17  script:
18    - ls -l

分析： citest1作业并没有获取上个阶段产出文件， 因为默认每个作业运行时都会重新下载代码；重新下载代码会把其他文件删除掉；

如何解决？

禁止后面的作业重复的下载代码；
使用artifact关键字，收集制品传递给其他作业；

因为作业可能被分配到不同的runner上运行的。

这里测试如下：

方法1：GIT_CHECKOUT

GIT_CHECKOUT变量，默认值为true，即作业每次运行都下载代码。按照我们目前的需求，需要禁止下载代码：

我们将此变量的值在全局配置为false，然后在第一个作业（.pre）中配置为true。也就实现了只在第一个作业下载代码而不会出现其他作业下载代码了。

1GIT_CHECKOUT: "false"

优化一下pipeline，仅在pipelineInit作业中运行代码下载，其他作业跳过；

 1variables:
 2  ENV_TYPE: "dev"
 3  GIT_CHECKOUT: "false" 
 4
 5pipelineInit:
 6  tags:
 7    - build
 8  stage: .pre
 9  variables:
10    GIT_CHECKOUT: "true" 
11  script:
12    - ls -l 
13
14cibuild:
15  tags:
16    - build
17  stage: build
18  script:
19    - ls -l 
20    - echo 123 >test.yaml 
21    - ls -l 
22
23citest1:
24  tags:
25    - build
26  stage: test
27  script:
28    - ls -l

查看citest1 作业中的输出，发现工作目录中已经存在之前作业的产出文件；

🍀 自己测试存在的问题

老师，我在"gitlab ci-cd语法"这一节里，做“解决job运行重新下载代码”实验时，利用“GIT_CHECKOUT”方式测试后，.pre阶段能看到下载的代码，但是后面2个阶段没看到下载下来的代码，帮看看下，多谢@ZeYang

041e8df4907f0bae05504aae56a72df

9fcfd289d59c73d25357f1b53760591

5b61587c37affe5cc7b926b0d7ba7e3

5c2eddb7a215dca2ec90146ea6e8acd

我这个问题好奇怪哦，老师的实验现象及文档上的都没问题……；

自己重启了gitlab还是不行……；

自己重新注册下gitlab-ci runner再看下：……还是不行。。。；

最后发现了问题：。。。

默认这里是git fetch，git shallow clobe值为20。

但是在运行流水线时，报错：

经过百度，说是要在项目-设置-ci/cd-General pipelines里设置为git clone才行。

设置后，再次运行流水线：

此时，发现是ok的。

但是，在测试利用GIT_CHECKOUT下载代码时，就出现了问题，和老师的现象不一样

排查了好多问题，都解决不了……

报错如下：（在此步骤的上面）

最后，自己将项目-设置-ci/cd-General pipelines里设置为git fetch，然后把下面的git shadow clone设置为0后，再次运行流水线,就符合预期效果了。

CI代码：

 1variables:
 2  ENV_TYPE: "dev"
 3  GIT_CHECKOUT: "false" 
 4
 5pipelineInit:
 6  tags:
 7    - build
 8  stage: .pre
 9  variables:
10    GIT_CHECKOUT: "true" 
11  script:
12    - ls -l 
13
14cibuild:
15  tags:
16    - build
17  stage: build
18  script:
19    - ls -l 
20    - echo 123 >test.yaml 
21    - ls -l 
22
23citest1:
24  tags:
25    - build
26  stage: test
27  script:
28    - ls -l

很奇怪，这是为什么呢？？

⚠️ 汇总：

这个问题原因找到了。

之前项目里默认配置的是git fetch，Git shallow clone=20，但是后续跑流水线时报错，百度了下，就改成git clone。

但是后面在做GIT_CHECKOUT解决job运行重新下载代码时，测试现象和课程上的不一样。

最后改成了git fetch，Git shallow clone=0，现象就一致了。

方法2：Artifacts

在作业结束时，收集作业中的文件或目录并以附件的形式保存在关联的作业中。作业运行完成后，制品将被存储到GitLab，并且可以在GitLab UI中下载。

1  artifacts:
2    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
3    when: on_success
4    expire_in: '1 week'
5    paths:
6      - target/*.jar

name : 定义所创建的制品存档的名称；
when ：定义何时进行制品收集；
expire_in : 制品的过期时间，过期自动清理；
paths: 定义要收集的制品文件或者目录信息；

1  dependencies:
2    - build   ## 作业名称

dependencies：

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

基于artifacts和dependencies调整pipeline:

 1variables:
 2  ENV_TYPE: "dev"
 3  #GIT_CHECKOUT: "false" 
 4
 5pipelineInit:
 6  tags:
 7    - build
 8  stage: .pre
 9  #variables:
10    #GIT_CHECKOUT: "true" 
11  script:
12    - ls -l 
13
14cibuild:
15  tags:
16    - build
17  stage: build
18  script:
19    - ls -l 
20    - echo 123 >test.yaml 
21    - ls -l 
22  artifacts:
23    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
24    when: on_success
25    expire_in: '1 week'
26    paths:
27      - test.yaml
28
29citest1:
30  tags:
31    - build
32  stage: test
33  dependencies:
34    - cibuild
35  script:
36    - ls -l

查看结果：citest1作业会下载cibuild作业生成的制品；

以上问题已解决。

gitlab配置邮件通知反馈

编辑/etc/gitlab/gitlab.rb文件开启gitlab email。这里以QQ邮箱为例

 1### GitLab email server settings
 2###! Docs: https://docs.gitlab.com/omnibus/settings/smtp.html
 3###! **Use smtp instead of sendmail/postfix.**
 4
 5gitlab_rails['smtp_enable'] = true
 6gitlab_rails['smtp_address'] = "smtp.qq.com"
 7gitlab_rails['smtp_port'] = 465
 8gitlab_rails['smtp_user_name'] = "2560350642@qq.com"
 9gitlab_rails['smtp_password'] = "exnyvccnekcccjdgwecga"
10gitlab_rails['smtp_domain'] = "smtp.qq.com"
11gitlab_rails['smtp_authentication'] = "login"
12gitlab_rails['smtp_enable_starttls_auto'] = true
13gitlab_rails['smtp_tls'] = true
14
15### Email Settings
16gitlab_rails['gitlab_email_enabled'] = true
17gitlab_rails['gitlab_email_from'] = '2560350642@qq.com'
18gitlab_rails['gitlab_email_display_name'] = 'GitLab Admin'

重新配置

1gitlab-ctl stop ;
2gitlab-ctl reconfigure ;
3gitlab-ctl start gitlab-ctl status

登录gitlab-rails控制台，发送测试邮件:

 1su - git
 2gitlab-rails console
 3
 4irb(main):002:0> Notify.test_email('2560350642@qq.com', 'test email', 'gitlab email test').deliver_now
 5
 6
 7Notify#test_email: processed outbound mail in 0.5ms
 8Delivered mail 5eba1b04de4e5_12903fe2ca0c79b0519ec@gitlab-995f97976-2nmb4.mail (1055.9ms)
 9Date: Tue, 12 May 2020 03:41:56 +0000
10From: GitLab Admin <2560350642@qq.com>
11Reply-To: GitLab Admin <noreply@192.168.1.200>
12To: 2560350642@qq.com
13Message-ID: <5eba1b04de4e5_12903fe2ca0c79b0519ec@gitlab-995f97976-2nmb4.mail>
14Subject: Message Subject
15Mime-Version: 1.0
16Content-Type: text/html;
17 charset=UTF-8
18Content-Transfer-Encoding: 7bit
19Auto-Submitted: auto-generated
20X-Auto-Response-Suppress: All
21
22<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
23<html><body><p>Message Body And Linuxea.com</p></body></html>
24
25=> #<Mail::Message:70243016426420, Multipart: false, Headers: <Date: Tue, 12 May 2020 03:41:56 +0000>, <From: GitLab Admin <2560350642@qq.com>>, <Reply-To: GitLab Admin <noreply@192.168.1.200>>, <To: 2560350642@qq.com>, <Message-ID: <5eba1b04de4e5_12903fe2ca0c79b0519ec@gitlab-995f97976-2nmb4.mail>>, <Subject: Message Subject>, <Mime-Version: 1.0>, <Content-Type: text/html; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>, <Auto-Submitted: auto-generated>, <X-Auto-Response-Suppress: All>>

测试邮件：

配置gitlab流水线状态通知

FAQ

TS：gitlab-ci运行作业报错`fatal: git fetch-pack: expected shallow list,fatal: The remote end hung up unexpectedly`-2023.5.10(已解决)

1、故障现象

自己在使用gitlab-ci跑job时，之前都没错的，但是后面报错了……

fatal: git fetch-pack: expected shallow list

fatal: The remote end hung up unexpectedly

2、解决办法

解决方法，修改gitlab的cicd配置，如下图所示：

这里设置为git clone后，保存配置。

测试

此时，就可以正常运行作业了。

参考链接

http://blog.sway.com.cn/?p=878

Gitlab全局或者项目里设置变量`Variables`

Variables：变量，比如说，这里可以存放一些密码，可以选择加密或不加密!

1、全局设置变量

2、项目里设置变量

gitlab是具有制品库功能的

Maximum artifacts size

gitlab是一体化的，不但有ci/cd功能，还具有制品库功能，制品仓库；

注意：gitlab的构建id这个是系统级别的，不一定按顺序来

方法：如何关闭自动ci/cd

1.全局层面设置： 全局->Settings->CI/CD->Continuous Intergration Deployment：

2.项目层面设置： 项目->Settings->CI/CD->Auto Devops：

GitLab & Jenkins

可以轻松集成，不像jenkins那么复杂。

集成和代码是绑定一起的，可能对开发平台比较友好。

如果企业里有专门的人来运维jenkins，那么还是建议用jenkins。

如果祖业的数量比较高的话，那么它的维护成本还是比较高的。

例如jenkins更新。

gitlab ci/cd也是gitlab里核心的一个功能！

gitlab ci/cd比jebjnins稍微简单点，不用写很多复杂的脚本
但是想要实现一些更为复杂的功能时，那也避免不了写脚本(写shell脚本)

同一个阶段，默认就是并行运行的

测试demo如下：

CI代码：

 1citest1:
 2  tags:
 3    - build
 4  stage: test
 5  script:
 6    - echo "Do a test here"
 7
 8
 9citest2:
10  tags:
11    - build
12  stage: test
13  script:
14    - echo "Do a test here"  
15
16
17citest3:
18  tags:
19    - build
20  stage: test
21  script:
22    - echo "Do a test here"

运行：

关于我

我的博客主旨：

排版美观，语言精炼；
文档即手册，步骤明细，拒绝埋坑，提供源码；
本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！

🍀 微信二维码 x2675263825 （舍得）， qq：2675263825。

🍀 微信公众号《云原生架构师实战》

🍀 语雀

https://www.yuque.com/xyy-onlyone

🍀 csdn https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

🍀 知乎 https://www.zhihu.com/people/foryouone

最后

好了，关于本次就到这里了，感谢大家阅读，最后祝大家生活快乐，每天都过的有意义哦，我们下期见！

📡

👤 作者: 余温Gueen

🔗 链接: https://wiki.xxdevops.cn/topic/ca99d

🌐 版权: 本站文章除特别声明外，均采用 CC BY-NC-SA 4.0 协议，转载请注明来自余温Gueen Blog！

推荐使用微信支付

推荐使用支付宝

上一篇 GitLabRunner安装部署下一篇 GitLAB&Jenkins

GitLab CI-CD

目录

GitLabCI/CD简介

GitLabCI/CD简介

gitlab ci/cd官方文档

Pipeline

Stages

Job

Runner

GitLabRunner安装部署

开发第一条Pipeline

1. gitlab-ci.yml

2. 流水线页面

3. Pipeline编辑器

Pipeline开发工具与设置

1.Pipeline开发工具

可视化编辑器

语法检测校验

作业运行日志

Pipeline环境变量

2.Pipeline设置

General pipelines

为项目自定义ci文件

为项目设置流水线状态标志

设置管道(pipeline)预览权限

Pipeline核心语法

stages 阶段控制

variables 环境变量

job 作业默认配置

job 作业运行控制

parallel 并行运行

needs 作业关联运行

rules根据变量/文件控制

根据条件（变量）判断： IF

根据文件判断: changes exists

allow_failure

variables

when

when 状态控制和运行方式

timeout作业运行超时时间

retry 作业失败后重试次数

allow_failure 允许作业失败

Pipeline运行控制

1.workflow 控制流水线

2.Git 选项跳过流水线

3.trigger 触发下游管道

4.API触发Pipeline

使用API触发

触发并传递参数

PipelineTemplate实践

extends

include

提交阶段流水线

流水线优化

1.过滤新建分支和tag的触发

2.解决job运行重新下载代码

方法1：GIT_CHECKOUT

方法2：Artifacts

gitlab配置邮件通知反馈

FAQ

TS：gitlab-ci运行作业报错fatal: git fetch-pack: expected shallow list,fatal: The remote end hung up unexpectedly-2023.5.10(已解决)

Gitlab全局或者项目里设置变量Variables

gitlab是具有制品库功能的

注意：gitlab的构建id这个是系统级别的，不一定按顺序来

方法：如何关闭自动ci/cd

GitLab & Jenkins

同一个阶段，默认就是并行运行的

关于我

最后

文档导航

本页导航

根据文件判断: `changes` `exists`

TS：gitlab-ci运行作业报错`fatal: git fetch-pack: expected shallow list,fatal: The remote end hung up unexpectedly`-2023.5.10(已解决)

Gitlab全局或者项目里设置变量`Variables`