什么是CI？（理解CI）

  • gitlab-ci是gitlab官方的一种持续集成(Continuous Integration)工具，通常用来进行日常的编译和自动化测试，避免提交上去的代码出现基础错误而影响项目进度。
  • 对于大的企业项目来说，往往是多人协同开发，并且项目周期都很长，需要将各种代码进行持续性的合并就称之为持续集成。
  • 比如有人可能会基于你所写的代码去实现其他的功能，如果你想要push自己新的修改，在此之前就要对新代码编译与测试，gitlab-ci就可以帮你完成这个功能，在push到gitlab上时，会自动触发编译测试与运行测试等功能。

使用CI的目的

  • 希望使用CI能够快速验证每次提交的可用性，经过自动化测试并同步到github。

持续集成的基本过程

  • 提交（合并）代码
  • 编译
  • 测试
  • 发布

具体的流程根据公司来制定.gitlab-ci.yml文件（此文件在下文会讲解），更加规范的公司会将CI流程做的更加具体。

gitlab-ci runner

ps:这里只是简单的普及概念，方便大家理解，具体的配置方法不在此赘述。

简单介绍一下runner,这个其实就是专门用来跑测试的主机，比如说我push新的提交之后，CI先会使用我提交的代码进行编译，然后将需要跑的TEST_CASE分配到真正运行的测试代码的主机上进行测试，这些配置好的主机就称之为runner。

.gitlab-ci.yml文件

这个文件中规定CI流程，最基础的流程：编译->分配->运行测试，这是有序流程，此流程就分为三个阶段（stage）。

  • job：在编译阶段可能会有很多的编译任务，每个独立的编译都是一个job。
  • stage：指定一组job在不同场景阶段执行。在同一stage下的job会并行执行。
  • only与except：指定触发条件，比如push的时候触发CI或者手动触发。
  • tags：选择允许哪些具备相同tag的runner执行该job。
  • when：失败执行、成功执行、手动执行、总执行。
  • artifacts：将此job制定的文件上传到服务器，可以传递给下一个job，使用dependencies: []可以禁止传递来的artifacts。