GitLab CI 自动流程简述

发表于 阅读次数： 本文字数： 1.2k 阅读时长 ≈ 4 分钟

什么是 GitLab CI

GitLab CI 是GitLab内置的进行持续集成的工具，只需要在仓库根目录下创建 .gitlab-ci.yml 文件，并配置GitLab Runner；每次提交代码的时候，gitlab 将自动识别并且使用 GitLab Runner 执行任务。

GitLab Runner

GitLab-Runner就是一个用来执行 .gitlab-ci.yml 脚本的工具。Runner 就像认真工作的工人，GitLab-CI 就是管理工人的中心，所有工人都要在 GitLab-CI 里面注册。当相应的项目发生变化时，GitLab-CI 就会通知相应的工人执行对应的脚本。gitLab-Runner 可以分类两种类型：Shared Runner（共享型）和 Specific Runner（指定型）。

  • Shared Runner：所有工程都能够用的，只有系统管理员能够创建。
  • Specific Runner：只有特定的项目可以使用。
  1. 安装
    官方文档: Install GitLab Runner
  2. 注册
    • 输入 GitLab URL 地址
    • 输入注册 Token
    • 指定runner executor 一般为shell

!!! Warning
1. 若是 powershell 需将配置文件里shell改为: shell = "powershell"
2. Runner 默认日志输出太小，可通过更改output_limit = 40960进行调整
3. Runner 默认为串行方式，可通过concurrent = 2指定能并行运行的数量

GitLab CI 流程

每个推送到 Gitlab 的提交都会产生一个与该提交关联的管道(pipeline)，管道(pipeline)是一个分成不同阶段(stage)的作业(job)的集合。多个 Stage 是按照顺序执行的，如果其中任何一个 Stage 失败，则后续的 Stage 不会被执行，整个 CI 过程被认为失败。
ci

.gitlab-ci.yml 文件

GitLab CI 使用 YAML 文件.gitlab-ci.yml来管理项目配置。该文件必须存放于项目仓库的根目录，并且包含了你的项目如何被编译的描述语句,YAML文件使用一系列约束叙述定义了Job启动时所要做的事情。

Job

Job 是.gitlab-ci.yml文件中最基本的元素，由一系列参数定义了任务启动时所要做的事情，用户可以创建任意个任务；每个任务必须有一个独一无二的名字，但有一些保留 keywords 不能用于 Job 名称.
Job 被定义为顶级元素，并且至少包括一条script语句，如果一个 Job 没有显式地关联某个 Stage，则会被默认关联到 test Stage。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
stages:
  - build
  - test
  - deploy

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

before_script和after_script

before_script 是用于定义一些在所有任务执行前所需执行的命令, 包括部署工作，可以接受一个数组或者多行字符串。after_script 用于定义所有 job 执行过后需要执行的命令，可以接受一个数组或者多行字符串。例如可以在 before_script 做好ssh连接的准备。

1
2
3
4
5
6
7
8
9
10
11
12
#定义全局 before_script:
default:
  before_script:
    - global before script
#覆盖全局before_script
job:
  before_script:
    - execute this instead of global before script
  script:
    - my command
  after_script:
    - execute this after my script

rules

rules 用来限定 jobs 在什么情况下能够运行

1
2
3
4
5
6
7
8
9
job:
  script: echo "Hello, Rules!"
  rules:
    # 发起了 merge request
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    # 推送了 tag 版本号
    - if: $CI_COMMIT_TAG
    # commit 信息以 run ci 开头
    - if: $CI_COMMIT_MESSAGE =~ /^run ci/

artifacts

用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。Job 完成后（默认为仅成功后生成），工件将被发送到 GitLab UI 中提供下载。
默认情况下 artifacts 仅在作业成功时生成、且会在下一个 stage 时下载到当前工作路径下，如果不需要下载则添加关键字 dependencies: []。

1
2
3
4
5
6
7
8
9
10
11
12
job:
  script: do something 
  artifacts:
    # 失败后生成，默认为仅成功时生成
    when: on_failure
    # 文件名，可以用内置变量
    name: ${CI_JOB_NAME}
    # 路径只能是相对于当前项目路径，可以使用通配符匹配
    paths:
      - binaries/
      - log/*.log
    dependencies: [] # 不需要下载

only 和 except

  • only 和 except 两个参数说明了job什么时候将会被创建
  • only 定义了 job 需要执行的所在分支或者标签
  • except 定义了 job 不会执行的所在分支或者标签

Run Pipeline

  1. 提交代码时自动触发
  2. gitlab 上手动执行
    在项目所在仓库里进入 CI/CD, 点击: Run Pipeline
  3. Runner 本地运行
    gitlab-runner exec shell 'job1'
    gitlab-runner exec shell 'job2'

如何跳过gitlab-ci流程

在 commit 信息中包含[ci skip]或 [skip ci],提交到仓库以后就会跳过本次 CI

如何让某个步骤跳过下载源码

在相对应的任务修改默认值为 false

1
2
3
variables:
   GIT_CHECKOUT: "false"

使用上的一些报错

fatal: git fetch-pack: expected shallow list

Centos 7 自带的 git 版本是 1.8.3.1，由于版本太低不支持最新的API，需要升级 git 版本。

  1. 安装 git 源
    yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm
  2. 更新 git
    yum update git