了解gitlab-ci流程
作用
GitLab CI是GitLab内置的进行持续集成的工具。它的中心思想是,当每一次push到GitLab的时候,都会触发一次脚本执行,脚本的内容可以包括测试、编译、部署等一系列自定义的内容。
在GitLab中,要使用CI,需要在仓库根目录下创建一个名为.gitlab-ci.yml
的文件,并配置GitLab Runner。每次提交时,GitLab会自动识别到.gitlab-ci.yml
文件,并使用GitLab Runner执行该脚本。
GitLab Runner是一个用来执行.gitlab-ci.yml
脚本的工具。可以将其视为认真工作的工人,而GitLab CI则是管理工人的中心。所有的工人都需要在GitLab CI中注册,并表明自己是为哪个项目服务。当相应的项目发生变化时,GitLab CI就会通知相应的工人执行对应的脚本。
GitLab CI与持续集成(Continuous Integration,简称CI)的概念紧密相连。持续集成指的是频繁地将代码集成到主干,通常一天多次。持续集成的优势在于可以快速发现错误,因为每完成一点更新,就集成到主干,这有助于快速发现并定位错误。此外,持续集成还可以防止分支大幅偏离主干,确保软件在不断迭代中保持高质量。
- CI: Continuous Integration(持续集成)
- CD: Continuous Delivery(连续交付)
- CD: Continuous Deployment(持续部署)
了解
参考:https://zhuanlan.zhihu.com/p/184936276
参考:https://www.cnblogs.com/mrxccc/p/16504723.html
运行机制
(1) .gitlab-ci.yml文件:通过在项目根目录下配置.gitlab-ci.yml文件,可以控制ci流程的不同阶段,例如install/检查/编译/部署服务器。gitlab平台会扫描.gitlab-ci.yml文件,并据此处理ci流程
(2) 触发:ci流程在每次团队成员push/merge后之后触发。每当你push/merge一次,gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件,如果有,它会执行你在里面编写的脚本,并完整地走一遍从intall => eslint检查=>编译 =>部署服务器的流程
(3)gitlab-runner:gitlab-ci提供了指定ci运行平台的机制,它提供了一个叫gitlab-runner的软件,只要在对应的平台(机器或docker)上下载并运行这个命令行软件,并输入从gitlab交互界面获取的token,就可以把当前机器和对应的gitlab-ci流程绑定,也即:每次跑ci都在这个平台上进行
(4)可视化:.gitlab-ci的所有流程都是可视化的,每个流程节点的状态可以在gitlab的交互界面上看到,包括执行成功或失败。如下图所示,因为它的执行看上去就和多节管道一样,所以我们通常用“pipeLine”来称呼它
(5).不同push/merge所触发的CI流程不会互相影响,也就是说,你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断,它们是互不影响的。这一个特点方便让测试同学根据不同版本进行测试。
(6)pipeline不仅能被动触发,也是可以手动触发的。
知识预备
- gitlab-ci涉及的抽象概念
- YML文件的基本语法规则
- .gitlab-ci.yml配置的特定关键字
gitlab-ci涉及的抽象概念
1、Pipeline & Job
Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程,它由许多个任务节点组成, 而这些Pipeline上的每一个任务节点,都是一个独立的Job
一个Pipleline有若干个stage,每个stage上有至少一个Job
2、Runner
在特定机器上根据项目的.gitlab-ci.yml文件,对项目执行pipeline的程序
分为两种: Specific Runner 和 Shared Runner
- Shared Runner是Gitlab平台提供的免费使用的runner程序,它由Google云平台提供支持,每个开发团队有十几个。对于公共开源项目是免费使用的,如果是私人项目则有每月2000分钟的CI时间上限。
- Specific Runner是我们自定义的,在自己选择的机器上运行的runner程序,gitlab给我们提供了一个叫gitlab-runner的命令行软件,只要在对应机器上下载安装这个软件,并且运行gitlab-runner register命令,然后输入从gitlab-ci交互界面获取的token进行注册, 就可以在自己的机器上远程运行pipeline程序了。
3、Executor
Specific Runner是在我们自己选择的平台上执行的,这个平台就是我们现在说到的“Executor”
4、总结
Pipeline
一次 Pipeline 其实相当于一次构建任务,里面可以包含多个流程(Stage
),比如自动构建、自动进行单元测试、自动进行代码检查等流程
任何提交或者 Merge Request 的合并都可以触发 Pipeline ;
Stage
- Stage有如下特点 :
- 所有 stages 会按照顺序运行,即当一个 stage 完成后,下一个 Stage才会开始
- 只有当所有 Stage 成功完成后,该构建任务
Pipeline
才算成功 - 如果任何一个 Stage失败,那么后面的 Stage 不会执行,该构建任务 (Pipeline) 失败
Job
- job表示构建工作,表示某个stage里面执行的工作 ;
- 一个stage里面可以定义多个job ;
- jobs有如下特点 :
- 相同 stage 中的jobs 会并行执行
- 相同 stage 中的 jobs 都执行成功时,该 stage 才会成功
- 如果任何一个job 失败,那么该 stage 失败,即该构建任务 (Pipeline) 失败
Runner就像一个个的工人,而Gitlab-CI就是这些工人的一个管理中心,所有工人都要在Gitlab-CI里面登记注册,并且表明自己是为哪个工程服务的。当相应的工程发生变化时,Gitlab-CI就会通知相应的工人执行软件集成脚本
gitlab里面的runner叫Gitlab-Runner
,Gitlab-Runner是配合Gitlab-CI进行使用的。一般地,Gitlab里面的每一个工程都会定义一个属于这个工程的软件集成脚本,用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时,比如有人push了代码,GitLab就会将这个变动通知Gitlab-CI。这时Gitlab-CI会找出与这个工程相关联的Runner,并通知这些Runner把代码更新到本地并执行预定义好的执行脚本(也就是在Job执行流程
那个图中所示的第三步:script),所以,Gitlab-Runner就是一个用来执行软件集成脚本script
的东西。
Gitlab-Runner可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型)。
- Shared Runner:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。
- Specific Runner:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。
关于Gitlab-runner的安装,会以单独一个文章进行介绍,注册runner会对应一个tag,记住这个tag;
YML文件的基本语法规则
- YML通过缩进组织层级
- YML里允许通过#符号编写注释
- YML也是由对象,数组,以及对象和数组的嵌套结构组成的。
例如数组
colors
- red
- blue
- yellow
示例
install-job: # 注释
tags:
- sss
stage: install
script:
- npm install
对象写法:
people:
name: zhangsan
age: 14
gitlab-ci.yml配置特定关键字
- stages
- stage
- script
- tags
stages
stages定义在YML文件的最外层,它的值是一个数组,用于定义一个pipeline不同的流程节点
stages: # 分段
- install
- eslint
- build
- deploy
Job是pipeline的任务节点,它构成了pipeline的基本单元
stage/script/tags这三个关键字,都是作为Job的子属性来使用的,如下所示,install就是我们定义的一个Job
install:
tags:
- sss
stage: install
script:
- npm install
stage
是一个字符串,且是stages数组的一个子项,表示的是当前的pipeline节点。
- 正在执行是蓝色
- 尚未执行是灰色
- 执行成功是绿色
- 执行失败是红色
script
它是当前pipeline节点运行的shell脚本(以项目根目录为上下文执行)。
这个script是我们控制CI流程的核心,我们所有的工作:从安装,编译到部署都是通过script中定义的shell脚本来完成的。
如果脚本执行成功,pipeline就会进入下一个Job节点,如果执行失败那么pipeline就会终止
tags
tags是当前Job的标记,这个tags关键字是很重要,因为gitlab的runner会通过tags去判断能否执行当前这个Job
例如我们在gitlab的面板中能看到当前激活的runner的信息
Gitlab项目首页=> setting => CI/CD => Runners
实战
编写一个hello world
Ubuntu机器上:有一个hello world程序
1、在平台上下载并安装Gitlab-runner命令行
官方参考:https://docs.gitlab.com/runner/install/
ubuntu上的安装
①Add the official GitLab repository
添加官网GitLab 仓库
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
②Install the latest version of GitLab Runner, or skip to the next step to install a specific version
安装GitLab Runner的最新版本,或跳到下一步安装特定版本
sudo apt-get install gitlab-runner
③To install a specific version of GitLab Runner
安装特定版本
apt-cache madison gitlab-runner
sudo apt-get install gitlab-runner=16.5.0
④查看版本
gitlab-runner
11.2.0 (11.2.0)
注释:也可直接使用deb包安装
若下载不成功,配置镜像源,见后面的补充
2、创建和注册runner
官方参考:https://docs.gitlab.com/ee/tutorials/create_register_first_runner/
Runner 安装完毕,在真正使用之前需要先进行注册。注册的目的是让 Runner 和GitLab 实例建立链接通道,当GitLab 实例中的项目有 CI/CD Pipeline需要执行的时候,就会通过这个注册的 Runner 来执行.
创建项目获取获取Gitlab实例的URL
和Token
登陆https://docs.gitlab.com/runner/register/index.html创建一个项目
获取Gitlab实例的URL
和Token
,这些内容可以通过项目的 Setting –> CI/CD –> Runner 选项来获取
初始创建一个tag再创建一个runner
Register with a runner authentication token
①Run the register command
sudo gitlab-runner register
全乎
gitlab-runner register --url https://gitlab.com --token glrt-_sQ1WZeWsgnHroH2W4zM
If you are behind a proxy, add an environment variable and then run the registration command:
export HTTP_PROXY=http://yourproxyurl:3128
export HTTPS_PROXY=http://yourproxyurl:3128
sudo -E gitlab-runner register
②Enter your GitLab URL
- For runners on GitLab self-managed, use the URL for your GitLab instance. For example, if your project is hosted on
gitlab.example.com/yourname/yourproject
, your GitLab instance URL ishttps://gitlab.example.com
. - For runners on GitLab.com, the
gitlab-ci coordinator URL
ishttps://gitlab.com
.
③Enter the runner authentication token
④Enter a name for the runner
⑤Enter the type of executor
交互界面如下
Runtime platform arch=amd64 os=linux pid=15627 revision=853330f9 version=16.5.0
Running in system-mode.Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://gitlab.com]:
Verifying runner... is valid runner=_sQ1WZeWs
Enter a name for the runner. This is stored only in the local config.toml file:Enter an executor: custom, docker, parallels, ssh, docker+machine, kubernetes, docker-windows, shell, virtualbox, docker-autoscaler, instance:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"
3、激活Runner
注册完了可能还需要激活,这时我们可以看下面板,如果有个黑色的感叹号,这说明Runner注册成功了,但是尚未激活(如果是绿色的说明已经激活,本步骤跳过)
gitlab-runner verify
gitlab-runner restart
再刷新下网页,黑色的变绿色就说明激活成功了
4、Runner的使用
①创建YAML的配置文件,不用手动创建,回到Gitlab项目根目录,选择配置CI/CD-编辑-创建新的CI/CD流水线-浏览模板(新的窗口打开)-选择C++.gitlab-ci.yml-复制配置内容-回到根项目的配置粘贴复制的配置内容。
实际操作自动创建提交-无需复制
②拉取cicd_helloworld的项目到本地,创建helloworld.cpp
sudo apt-get install git
git clone https://gitlab.com/circlegroup/cicd_hellowold.git
git config --global user.email "[email protected]"
git config --global user.name "Your Name"
代码
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
③创建test的测试脚本
#!/bin/bash
g++ helloworld.cpp -o helloworld
wait
./helloworld
④修改yml文件
# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/C++.gitlab-ci.yml
# use the official gcc image, based on debian
# can use verions as well, like gcc:5.2
# see https://hub.docker.com/_/gcc/
image: gcc
build:
stage: build
# instead of calling g++ directly you can also use some build toolkit like make
# install the necessary build tools when needed
# before_script:
# - apt update && apt -y install make autoconf
script:
- echo "Compiling the code..."
- g++ helloworld.cpp -o helloworld
- echo "Compile complete."
artifacts:
paths:
- helloworld
# depending on your build setup it's most likely a good idea to cache outputs to reduce the build time
# cache:
# paths:
# - "*.o"
# run tests using the binary built before
test:
stage: test
script:
- chmod +x helloworld.sh
- ./helloworld.sh
问:
docker的build阶段为什么g++文件就行编译呢?
helloworld.cpp等代码是怎么到宿主机上的?
当前目录是什么呢?
⑤提交(PUSH))代码触发流水线自动运行
git add .
git commit -m "helloworld"
git push origin main
⑥回到网页打开流水线,会看到流水线正在执行,如果build没有完成的话,还没有到test的步骤。
查看build的信息
Build编译通过后会自动运行test测试。
查看test的信息
参考汇总:
GItlab-ci CI/CD部署C++ helloworld项目_gitlab-ce cicd c++-CSDN博客
Tutorial: Create, register, and run your own project runner | GitLab
Gitlab-ci:从零开始的前端自动化部署 - 知乎 (zhihu.com)
标签:ci,GitLab,runner,流程,gitlab,CI,Runner From: https://www.cnblogs.com/circlelll/p/17988710