GitLab CI 持续集成

2023年 1月 4日 71.2k 0

1. 基本概念

  • GitLab-CI:GitLab 提供的持续集成系统,管理项目的构建状态,通过 GitLab Runner 来执行构建任务。
  • GitLab-Runner:用于执行构建任务,.gitlab-ci.yml 的 script 部分的运行就是由 GitLab-Runner 来完成。
  • .gitlab-ci.yml:在git项目的根目录下的一个文件,记录了一系列的阶段和执行规则。GitLab-CI 在 git push 后会解析它,根据里面的内容调用 GitLab-Runner 来执行。
  • Pipeline:一次 Pipeline 相当于一次构建任务,里面可以包含多个流程,比如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
  • Stages:构建阶段,在一次 Pipeline 中可以定义多个 Stages,所有 Stages 会按照顺序运行,如果任何一个 Stage 失败,那么后面的 Stages 不会执行。
  • Jobs:构建任务,每个 Stage 里面执行的任务。一个 Stage 可以有多个 Job ,全部 Job 会并行执行。

2. 安装 GitLab-Runner

以 Ubuntu 为例:

1
2
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
apt-get install gitlab-ci-multi-runner

3. 注册 Runner

Runner 需要注册到 GitLab 才可以被项目使用,一个 gitlab-ci-multi-runner 服务可以注册多个 Runner。

1
gitlab-ci-multi-runner register

此时,需要输入一系列 Runner 的相关参数。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
> http://yourdomain.com/ci # 输入 gitlab-ci 的 URL 地址,这里配置为 GitLab 地址 的 `/ci` 路径。
Please enter the gitlab-ci token for this runner:
> XXXXXXXXX # 在【admin area】 页面的 【Overview】- 【Runners】中,可以找到这里需要的 token
Please enter the gitlab-ci description for this runner:
> shell-runner # 这里可以随便输入
Whether to lock Runner to current project [true/false]:
> false
Please enter the executor: docker, parallels, shell, kubernetes, docker-ssh, ssh, virtualbox, docker+machine, docker-ssh+machine:
> shell #如果主要通过命令,执行构建,那么选 shell

查看 Runner 的状态

1
gitlab-ci-multi-runner list 

此时,GitLab 的项目并不能使用新建的 Runner,在【admin area】 页面的 【Overview】- 【Runners】点击编辑,将新建的 Runner 授权 【enable】给项目使用。

4. .gitlab-ci.yml

项目的文件结构:在项目的一级目录下,新建 .gitlab-ci.yml文件,GitLab-CI 指定的文件名。内容如下:.gitlab-ci.yml

1
2
3
4
5
6
7
8
9
stages:
  - build

job_name:
  stage: build
  script:
    - cd my-app
    - echo "start build"
    - mvn package

主要是两条命令:

  • cd 命令,进入 pom.xml 所在目录
  • mvn 命令,打包项目。

.gitlab-ci.yml 文件保存的是构建过程,采用 YAML 格式,语法规则在文末参考链接中有,构建关键字如下:

关键词必需描述
image no 使用docker image
services no 使用docker services
stages no 定义builds阶段
before_script no 定义每个job之前执行的脚本
after_script no 定义每个job之后执行的脚本
variables no 定义build变量
cache no 定义与后续job之间应缓存的文件

5. 执行构建

向 GitLab 提交代码之后,自动执行构建任务。在项目的 【Pipeline】-【Jobs】选项卡下,可以看到执行情况列表。在项目的 【Pipeline】-【Jobs】选项卡下,点击【Staus】栏下的颜色按钮【passed】、【failed】、【canceled】按钮,可以看到执行的 Console 输出详情。在详情的最后,可以看到,最终在 target 目录下生成了一个 my-app-1.0-SNAPSHOT.jar 可执行的 Java 文件。

6. 参考

  • https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
  • https://docs.gitlab.com/ee/ci/yaml/README.html
  • https://segmentfault.com/a/1190000006120164

相关文章

KubeSphere 部署向量数据库 Milvus 实战指南
探索 Kubernetes 持久化存储之 Longhorn 初窥门径
征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
那些年在 Terraform 上吃到的糖和踩过的坑
无需 Kubernetes 测试 Kubernetes 网络实现
Kubernetes v1.31 中的移除和主要变更

发布评论