总结：gitlab ci

小魏的博客

已于 2024-03-19 14:33:19 修改

阅读量3.2k

点赞数

分类专栏：其它文章标签： git gitlab ci

于 2022-04-08 09:19:16 首次发布

本文链接：https://blog.csdn.net/w2009211777/article/details/124012087

版权

其它专栏收录该内容

27 篇文章 7 订阅

订阅专栏

一、介绍

GitLab CI 是 GitLab 为了提升其在软件开发工程中作用，完善 DevOPS 理念所加入的 CI/CD 基础功能。可以便捷的融入软件开发环节中。通过 GitLab CI 可以定义完善的 CI/CD Pipeline。

现在很多公司用gitlab来作为代码仓库、版本控制软件，在加上gitlab的自动化持续集成部署工具ci/cd，它可以在代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作，非常方便。

官方文档：`.gitlab-ci.yml` keyword reference | GitLab

二、官方实例代码

gitlab-ci.yml 内容：

stages:
  - build
  - test
build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake
test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1
test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

分成三个部分

1、stages：定义管道的阶段，包含构建镜像，单元测试，部署

2、build-code-job：构建代码阶段，build阶段下的任务，任务名：build-code-job

3、test-code-job1，test-code-job2：测试阶段，test阶段下的任务，任务名：test-code-job1...

三、语法介绍

image

image 用于指定使用的 Docker 镜像，Runner 将启动这个镜像，并且在这个镜像中执行构建任务。

image 指令既可以是顶层指令，也可以作为 job 的子指令，表示针对某个 job 使用这个镜像。

before_script

before_script 中指定的 script 会在每个 job 之前执行。

Pipeline

Pipeline 相当于一个构建任务，里面可以包含多个流程，如依赖安装、编译、测试、部署等。
任何提交、打TAG或者 Merge Request 的合并都可以触发 Pipeline。

我们项目是创建TAG的时候触发CI。

Stages

stages 可以用来定义顺序指定的阶段，每个阶段执行的顺序按照定义的顺序，而 job 是执行单元，所以 job 中可以引用 stage。

并且在执行下一个 stage 之前，需要上一个 stage 中的所有 job 都成功完成，否则失败。

注意：

所有 Stages 按顺序执行，即当一个 Stage 完成后，下一个 Stage 才会开始
任一 Stage 失败，后面的 Stages 将永不会执行，Pipeline 失败
只有当所有 Stages 完成后，Pipeline 才会成功

但是：stages 并非像我们期望的那样工作，因为每个 job 是完全独立的，每个 job 都会重新下载代码，所以处于后面 stage 的 job 并不能利用前面 stage 执行的结果，例如：test stage 的任务不能直接使用 build stage 编译出来的代码。而是需要再次执行 build。

如下Stages包含build和publish两个阶段

stages:
    - build
    - publish

cache

在 .gitlab-ci.yml 配置文件中，cache 块定义了在相同项目的不同CI/CD作业（jobs）之间需要被保存和共享的文件和目录。这些文件通常是通用的依赖文件或编译输出，目的是加快后续作业的执行速度，因为不需要每次都从头开始下载或生成这些文件。

主要的作用和好处包括：

减少重复工作：如果多个作业使用相同的依赖项或编译结果，缓存可以避免每个作业都重新执行这些重复的步骤。
加快CI/CD流程：通过缓存大型依赖项或编译产物，可以减少作业的执行时间，因为它们在第一次下载或生成后就被保存了。
节省带宽：对于大型或频繁下载的依赖项，缓存可以减少从外部源下载的次数，这在带宽限制或者付费数据使用的情况下特别有用。
提高稳定性：通过缓存特定的依赖文件，你可以确保作业之间使用完全相同的版本，降低因为依赖更新导致的潜在问题和不一致性。

在 .gitlab-ci.yml 中，cache 块的使用示例：

cache:
        key: "${CI_PROJECT_NAME}_${CI_JOB_NAME}"
        untracked: true
        paths:
        - .m2/repository/
        - hubble-ui/node_modules/
        - .yarn

cache 可以是顶层元素，表示全局 cache，也就是为所有 job 都 cache；也可以 job 的子元素，此时表示只对这个 job 保留缓存。

Jobs

Job 指定任务名称，用户可以自定义名称，例如：job1, job2, myjob 等等。job 是构建任务执行的流程，包含一些关键字，下面介绍一些常用的，完整的文档可以参考官方文档。

script：

script 是 job 的必需子元素，指明执行的命令。例如：

job1:
  script:
    - echo "job start"
    - ./build.sh

stage

前面已经介绍过顶级元素 stages，stage 表示引用一个在 stages 中定义的 stage，如果不指名，默认为 test。

only

参考：Gitlab-CI job 配置文件 .gitlab-ci.yml 配置方式(翻译)_kunyus的博客-CSDN博客

只有满足 only 条件的 branches 和 tags 才会被运行。

只在指定的 git refs 上执行该任务，如下表示：job-release 只会在 hubble/hubble-manager 这个项目有 tag被创建时执行。

所以，我们要创建CI构建，我们是通过创建TAG的方式，至于哪个分支都可以。

job-release:
  only:
        - tags@hubble/hubble-manager

except

不在指定的 git refs 上执行该任务，和 only 作用相反。

only 和 except 之间的规则可以参考这里。

tags

指定具有所有指定 tag 的 Runner 才能执行该任务，例如：

job1:
  tags:
    - java
    - mysql

则只有具有 java 和 mysql tag 的 Runner 才能执行本任务。

when

前面在介绍 stags 的时候，我们知道，默认情况下，只有在前面一个 stage 中所有的任务都成功时，这一个 stage 的任务才会执行，但是，用户可以更改这种行为。

when 的合法值有 3 个：

on_success, 默认值
on_failure, 前一个 stage 中至少有一个任务失败
always, 总是执行

always 比较像 java 中 try .. catch .. finally 语句中的 finally，总是会执行，所以可以执行一些 cleanup 的任务。

注意：

相同 Stage 中的 Jobs 会并行执行
任一 Job 失败，那么 Stage 失败，Pipeline 失败
相同 Stage 中的 Jobs 都执行成功时，该 Stage 成功

上面说的概念，没有提到任务的实际执行者. 那任务在哪里执行呢？

四、开启 GitLab CI

1、介绍

总的来说，要使用 GitLab CI，首先，需要在项目中新建一个 CI 配置文件 .gitlab-ci.yml，这是一个 YAML 语法文件，控制着怎样执行 CI 任务，也就是说，CI 任务本身也是当作代码管理起来的，所以，任何改动都可以 review，都可以找到历史。

一旦开启了 CI，你会发现 CI 无处不在：

merge request
pipelines
commits
...

很多地方你都能看到当前项目的构建状态，各个 commit 的构建状态，非常酷！

2、CI在哪？

如下图导航栏中的：Pipelines，有的版本显示为CI / CD，即表示CI模块，在这里我们能看到CI的具体情况，有哪些CI任务等

如下可以看出来：

CI执行状态
CI的执行编号
CI的提交信息
CI的构建阶段，每个阶段的执行情况
CI的时间

3、 CI设置

如下进行设置

这里简单解释下该页面中的几个部分的内容：

Runners：当前为这个项目配置的 Runner，Runner 负责执行 CI 任务
Variables：配置保密的变量，不用提交到 .gitlab-ci.yml 中
Triggers：用户可以通过项目的 Triggers 来手动触发 build
CI/CD Pipelines：一些通用设置

现在，我们来添加一个 CI 任务，看看 CI 具体是怎么工作的。

4、开启 CI

GitLab 所有项目都默认开启了 CI，如果有项目没有开启，则可以通过下面的方法打开。

5、执行CI

GitLab 中所有项目都开启了 CI 功能，因为 CI 功能已经是 GitLab 的一部分了，但是，要使用 CI，项目的根目录下必须有一个文件 .gitlab-ci.yml，它定义了具体的 CI 任务。下图是案例：

image: docker-registry.xxx.xxx/library/ci-env-centos7:7-xxx-1
job-hello:
  script:
    - echo "hello GitLab CI"

首先使用 image 指令指定了一个 Docker 镜像，这是必须的，否则将使用 GitLab 提供的默认镜像。

在启动项目的 CI 任务时，GitLab 会启动这个Docker 镜像，并且在容器中执行 CI 任务，所以，这个镜像应该安装好了所有 CI 任务需要的依赖。

然后，我们添加了一个 Job 叫做 job-hello，执行了一条 echo 命令。所以，当 GitLab 启动了指定的镜像后，首先会下载项目代码，然后开始执行 job-hello。

在 push 到私有的 fork repo 后，现在，需要提交一个 merge request 到 trunk repo。

五、gitlab runner配置

1、介绍

GitLab runner是任务的实际执行者，可以在 MacOS/Linux/Windows 等系统上运行。使用 golang 进行开发。同时也可部署在 k8s 上

如我们项目是在docker镜像中运行，然后将生成的jar包scp到我们的download机器，然后发版的时候通过download机器下载。

在 GitLab CI 中，有两种 Runner:

Shared Runner：工程效率团队添加并维护，所有项目都可以使用且默认使用，仅支持 Docker 类型的构建环境
Specific Runner：用户自己添加并维护，只对指定的项目可见

Specific Runner 用在 Shared Runner 不能满足需求的情况，例如：

不能在 Docker 环境中构建
不想用 Docker
不想用公共环境

gitlab上，需要指定服务器或docker容器去执行gitlab-ci.yml，这需要一些配置，包括：

在gitlab web页面上指定CI的执行服务器
在服务器上安装runner程序

gitlab-runner 配置过程 - 简书

2、安装

需要在制定的机器上安装runner程序。
增加可执行权限：chmod +x /usr/local/bin/gitlab-runner
创建 Linux user 和 HOME 目录： useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

3、注册

我们需要将runner机器注册到gitlab上，否则gitlab不知道该用哪个runner进行构建。

使用交互式注册：

gitlab-runner register
 # 根据提示输入
 # Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
 # 输入 http://gitlab.xxx.domain/hubble  -- 注意，这里到以及项目层就可以了，二级项目中可以去enable，比如hubble-manager可以去enable，platform也可以去enable不同的runner
 # Please enter the gitlab-ci token for this runner:
 # 输入 第一步中获取的注册 token
 # Please enter the gitlab-ci description for this runner:
 # 输入 过几年自己还能看懂的 Runner 信息描述
 # Please enter the gitlab-ci tags for this runner (comma separated):
 # 输入 特定的 tags，允许使用该 Runner、并标记了相同 tag （如果有 tag 的话）的 CI 任务才会分配到该 Runner 执行，tags 以英文 `,` 分隔
 # Whether to run untagged builds [true/false]:
 # 输入 true 或 false，表示是/否执行没有标记任何 tag 的 CI 任务
 # Whether to lock Runner to current project [true/false]:
 # 输入 true 或 false，表示是/否将 Runner 锁定到当前 GitLab 项目而不允许被分享到其他项目使用
 # 此时会显示一行信息表示开始注册，并成功
 # Registering runner... succeeded                     runner=<Runner ID>
 # Please enter the executor: shell, ssh, virtualbox, docker, docker-ssh, parallels:
 # 输入 shell，表示直接以主机 shell 模式执行 CI 任务
 # 此时会显示一行信息表示注册成功
 # Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded

注册后，GitLab Runner 生成了配置文件 /etc/gitlab-runner/config.toml，建议根据 CI 任务量和服务器承载能力修改其中的任务并发数配置 concurrent = 1

进入67这台发版机看下：果然配置好了runner

token已经注册到了gitlab上：

可以点击后面的按钮进行编辑

以上可见vps是用了指定的自制的runner，如下hubble的配置，可见hubble使用的是公共的runner

4、启动

安装为后台服务，生成 /etc/systemd/system/gitlab-runner.service，可使用 systemd 管理
```
 gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
```
启动（systemd 中 启动/停止/重启 分别为 start/stop/restart）
```
 systemctl start gitlab-runner
```

六、refs（引用）

背景：上面only关键字提到了git refs，不太懂，梳理下。

引用（Refs）是一种间接引用commit的方式。它是一种对用户来说更亲和的commit哈希的别名。使Git表示分支与标签的内部机制。

引用被作为一个普通的文本文件保存在.git/refs路径下，如下：

heads：描述了了在你仓库中所有的本地分支。
remotes：remotes文件夹将所有由git remote命令创建的所有远程分支存储为单独的子目录。在每个子目录中，可以发现被fetch进仓库的对应的远程分支。
tag：tag文件中存放的是tag而非分支

七、Job的only

这块有必要单独拿出来记录下，内容较多。

1、介绍

只有满足 only 条件的 branches 和 tags 才会被运行。

only 和 except 支持使用正则表达式。
only 和 except 支持使用特殊的关键字。
only 和 except 支持同时设置, 当同时设置时 only 和 except 将会同时起作用。
only 和 except 也可以用来指定 forks 作业的存储库路径。

2、only支持的关键字

关键字	含义
branches	当任何一个分支有push操作时触发job。当然，构建也会基于那个分支进行构建
tags	当任何一个分支有tag被创建时触发job。当然，构建也会基于那个分支进行构建
schedules
triggers
api
pushes
web
pipelines
external

3、案例

下面这个例子中，job 会跳过所有分支，只在以 issue- 开头的 ref时运行:

job:
  # use regexp
  only:
    - /^issue-.*$/
  except:
    - branches

下面这个例子中，job 只会执行有 tags 或者通过API触发器构建的 refs :

job:
  only:
    - tags
    - triggers
    - schedules

下面这个例子中，job 只会在gitlab-org/gitlab-ce项目的除master分支外的其他分支时才会运行。

job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce

only下可以填哪些东西呢？

only:
        - develop                     # 即develop分支
        - master                      # 即master分支
        - feature/tooltip_pingmesh    # 即feature/tooltip_pingmesh分支（也是个分支名）
        - tags                        # 即创建tag的时候

参考：Git系列之Refs 与 Reflog - SegmentFault 思否