共计 6470 个字符,预计需要花费 17 分钟才能阅读完成。
GitLab CI 是什么?
GitLab CI 是 GitLab 内置的进行继续集成的工具,只须要在仓库根目录下创立.gitlab-ci.yml 文件,并配置 GitLab Runner;每次提交的时候,gitlab 将自动识别到.gitlab-ci.yml 文件,并且应用 Gitlab Runner 执行该脚本。
Gitlab Runner
简介
GitLab-Runner 就是一个用来执行.gitlab-ci.yml 脚本的工具。Runner 就像认真工作的工人,GitLab-CI 就是治理工人的核心,所有工人都要在 GitLab-CI 外面注册。当相应的我的项目发生变化时,GitLab-CI 就会告诉相应的工人执行对应的脚本。
GitLab-Runner 个别都是配合 GitLab-CI 应用的, 在 GitLab 外面定义一个属于这个工程的软件集成脚本,用来自动化地实现一些软件集成工作。GitLab-Runner 执行状况如下:
- 本地代码改变
- 变动代码推送到 GitLab 上
- GitLab 将这个变动告诉 GitLab-CI
- GitLab-CI 找出这个工程相关联的 gitlab-runner
- gitlab-runner 把代码更新到本地
- 依据预设置的条件配置好环境
- 依据预约义的脚本 (个别是.gitlab-ci.yml) 执行
- 把执行后果告诉给 GitLab
- GitLab 显示最终执行的后果
Runner 类型
gitLab-Runner 能够分类两种类型:Shared Runner(共享型)和 Specific Runner(指定型)。
- Shared Runner:所有工程都可能用的,且只有系统管理员可能创立。
- Specific Runner:只有特定的我的项目能够应用。
Runner 搭建
1. Runner 装置 (Install GitLab Runner 官网)
GitLab Runner 能够在 GNU/Linux、macOS、FreeBSD 和 Windows 上装置和应用。你能够装置它:
- 在一个容器中。
- 通过手动下载二进制文件。
- 通过应用 rpm/deb 包的存储库。
以 Ubuntu 为例(Install GitLab Runner using the official GitLab repositories):
1. Add the official GitLab repository:
# For Debian/Ubuntu
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
2. Install the latest version of GitLab Runner, or skip to the next step to install a specific version:
# For Debian/Ubuntu/Mint
sudo apt-get install gitlab-runner
2. 获取 Runner 注册 Token
装置好 Runner 之后,须要向 Gitlab 进行注册,注册 Runner 须要 GitLab-CI 的 url 和 token。可依据需要注册抉择所需类型 Runner。
3. 注册 Runner
$ gitlab-ci-multi-runner register
WARNING: Running in user-mode.
WARNING: The user-mode requires you to manually start builds processing:
WARNING: $ gitlab-runner run
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://XXXXXXXXXXX/
Please enter the gitlab-ci token for this runner:
4UQMXXXXXXXXXXXufZV
Please enter the gitlab-ci description for this runner:
[cn0314000510l]: gitlab-ci-demo
Please enter the gitlab-ci tags for this runner (comma separated):
v1
Whether to run untagged builds [true/false]:
[false]:
Whether to lock Runner to current project [true/false]:
[false]:
Registering runner... succeeded runner=4UQMVEL5
Please enter the executor: docker, docker-ssh, parallels, docker+machine, shell, ssh, virtualbox, docker-ssh+machine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
接着咱们就是能够在该我的项目: setting — CI/CD — Runners activated for this project 看到
gitlab-ci-demo 这个 Runner。
相干概念
管道(pipeline)
每个推送到 Gitlab 的提交都会产生一个与该提交关联的管道 (pipeline),若一次推送蕴含了多个提交,则管道与最初那个提交相关联,管道(pipeline) 就是一个分成不同阶段 (stage) 的作业 (job) 的汇合。
阶段(Stage)
阶段是对批量的作业的一个逻辑上的划分,每个 GitLab CI/CD 都必须蕴含至多一个 Stage。多个 Stage 是依照程序执行的,如果其中任何一个 Stage 失败,则后续的 Stage 不会被执行,整个 CI 过程被认为失败。
以图中所示为例,整个 CI 环节蕴含三个 Stage:build、test 和 deploy。
- build 被首先执行。如果产生谬误,本次 CI 立即失败;
- test 在 build 胜利执行结束后执行。如果产生谬误,本次 CI 立即失败;
- deploy 在 test 胜利执行结束后执行。如果产生谬误,本次 CI 失败。
下图是 Gitlab 对阶段和阶段状态的展现:
作业(Job)
作业就是运行器 (Runner) 要执行的指令汇合,Job 能够被关联到一个 Stage。当一个 Stage 执行的时候,与其关联的所有 Job 都会被执行。在有足够运行器的前提下, 同一阶段的所有作业会并发执行。作业状态与阶段状态是一样的,实际上,阶段的状态就是继承自作业的。
作业必须蕴含 script(由 Runner 执行的 shell 脚本),随着我的项目越来越大,Job 越来越多,Job 中蕴含的反复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。
Job 的执行过程中往往会产生一些数据,默认状况下 GitLab Runner 会保留 Job 生成的这些数据,而后在下一个 Job 执行之前(甚至不局限于当次 CI/CD)将这些数据恢复。这样即使是不同的 Job 运行在不同的 Runner 上,它也能看到彼此生成的数据。
在理解了 Job 配置的 script、before_script、after_script 和 cache 当前,能够将整个 Job 的执行流程用一张图概括:
创立.gitlab-ci.yml 文件
什么是.gitlab-ci.yml 文件
GitLab CI 应用 YAML 文件 (.gitlab-ci.yml) 来治理我的项目配置。该文件寄存于我的项目仓库的根目录,并且蕴含了你的我的项目如何被编译的形容语句。YAML 文件应用一系列束缚叙述定义了 Job 启动时所要做的事件。
Job
Job 是.gitlab-ci.yml 文件中最根本的元素,由一系列参数定义了工作启动时所要做的事件,用户能够创立任意个工作;每个工作必须有一个举世无双的名字,但有一些保留 keywords 不能用于 Job 名称,image,services,stages,types,before_script,after_script,variables,cache。
Job 被定义为顶级元素,并且至多包含一条 script 语句,如果一个 Job 没有显式地关联某个 Stage,则会被默认关联到 test Stage。
示例:
ob1:
# 关联到 bulid 阶段
stage: build
# 所需执行的脚本
script:
- execute-script-for-job1
参数详情
上面是对于配置 CI/CD 管道的罕用参数具体阐明。
stages
用于定义所有作业 (job) 能够应用的全局阶段,gitlab-ci.yml 容许灵便定义多个阶段,stages 元素的程序定义了作业执行的程序。Job 关联的 stage 名雷同时,该多个 Job 将并行执行(在领有足够 Runner 状况下)。下一个阶段的 job 将会在前一个阶段的 job 都实现的状况下执行。
如果文件中没有定义 stages,那么则默认蕴含 build、test 和 deploy 三个 stage。Stage 中并不能间接配置任何具体的执行逻辑,具体的执行逻辑应该在 Job 中配置。
注:如果想要管制某一个 stage 在最开始,或者最初执行,能够应用.pre 和 .post 关键字
示例:
stages:
- build
- test
- deploy
stage
阶段是依据每个 Job 定义的,并且依赖于全局定义的阶段。它容许将作业 (Job) 分组到不同的阶段。示例:
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
script
script 是一段由 Runner 执行的 shell 脚本。
示例:
job:
script: "bundle exec rspec"
这个参数也能够应用数组蕴含好几条命令:
job:
script:
- uname -a
- bundle exec rspec
有些时候,script 命令须要被单引号或者双引号所包裹。举个例子,命令中包涵冒号的时候,该命令须要被引号所包裹,这样 YAML 解析器才晓得该命令语句不是“key: value”语法的一部分。当命令中包涵以下字符时须要留神打引号:: {} [] , & * #? | – < > = ! % @ `
image and services
这两个选项容许开发者指定工作运行时所需的自定义的 docker 镜像和服务。示例:
# 为每个作业定义不同的映像和服务
test:2.1:
image: ruby:2.1
services:
- postgres:9.3
script:
- bundle exec rake spec
test:2.2:
image: ruby:2.2
services:
- postgres:9.4
script:
- bundle exec rake spec
before_script 和 after_script
before_script 是用于定义一些在所有工作执行前所需执行的命令, 包含部署工作,能够承受一个数组或者多行字符串。after_script 用于定义所有 job 执行过后须要执行的命令,能够承受一个数组或者多行字符串。例如能够在 before_script 做好 ssh 连贯的筹备。
注:before_script 能够针对全副工作,也能够针对单个工作。
示例:
# 定义全局 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
only and except
- only 和 except 两个参数阐明了 job 什么时候将会被创立:
- only 定义了 job 须要执行的所在分支或者标签
- except 定义了 job 不会执行的所在分支或者标签
以下是这两个参数的几条用法规定:
- only 和 except 如果都存在在一个 job 申明中,则所需援用将会被 only 和 except 所定义的分支过滤
- only 和 except 容许应用正则
- only 和 except 容许应用指定仓库地址,然而不 forks 仓库
此外,only 和 except 容许应用以下一些非凡关键字:
值 | 形容 |
---|---|
branches | 当一个分支被 push 上来 |
tags | 当一个打了 tag 的分支被 push 上来 |
api | 当一个 pipline 被 piplines api 所触发调起,详见 piplines api(https://docs.gitlab.com/ce/api/pipelines.html) |
external | 当应用了 GitLab 以外的 CI 服务 |
pipelines | 针对多我的项目触发器而言,当应用 CI\_JOB\_TOKEN 并应用 gitlab 所提供的 api 创立多个 pipelines 的时候 |
pushes | 当 pipeline 被用户的 git push 操作所触发的时候 |
schedules | 针对预约好的 pipline 而言(每日构建一类~,具体请看 https://docs.gitlab.com/ce/user/project/pipelines/schedules.html) |
triggers | 用 token 创立 piplines 的时候 |
web | 在 GitLab 页面上 Pipelines 标签页下,你按了 run pipline 的时候 |
上面的例子,job 将会只在 issue- 结尾的 refs 下执行,反之则其余所有分支被跳过:
job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches
验证.gitlab-ci.yml
咱们先创立一个.gitlab-ci.yaml 文件:
stages:
- build
- test
- deploy
job 1:
stage: build
script: uname -a
job 2:
stage: test
script: uname -a
GitLab CI 的每个实例都有一个名为 Lint 的嵌入式调试工具,它能够验证.gitlab-ci.yml 文件的内容,进入我的项目仓库 ->CI/CD->CI Lint。
Run Pipeline
形式一、gitlab 上执行(不须要应用咱们本地装置的 gitlab-runner)
进入 CI/CD, 点击: Run Pipeline, 如下图
咱们点击上图的job 1
或者 job 2
就能够看到输入。
形式二、本地执行
在 gitlab 上配置新我的项目的 CI 的时候,须要编写我的项目的 .gitlab-ci.yml 文件。
每次批改 .gitlab-ci.yml 文件之后都要执行 git push 让 GitLab 去构建, 来验证以后的 CI 脚本是否能正确构建,甚是麻烦,同时减少了很多无养分的 Git 提交。所以咱们个别先本地构建好,而后提交.gitlab-ci.yaml
1. 拉取对应我的项目的仓库代码,切换到所需分支
2. 进入我的项目根目录(也就是有 .git 的目录)3. 执行命令进行验证:(终端能够看到输入)
gitlab-runner exec shell 'job 1'
gitlab-runner exec shell 'job 2'
参考文章
- GitLab CI 介绍——入门篇
- Gitlab-CI 应用教程
- 应用 gitlab-runner 本地验证.gitlab-ci.yml