了解gitlab-ci流程

了解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 is https://gitlab.example.com.
  • For runners on GitLab.com, the gitlab-ci coordinator URL is https://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 "you@example.com"
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)

posted @ 2024-01-26 10:02  circlelll  阅读(232)  评论(0)  编辑  收藏  举报