Gitlab CI/CD 入门教程

前言

开发人员常常提到的 CI/CD 是什么?

  • 是用于集成测试的工具,每次提交代码后自动检测、构建和进行单元测试的过程。这一整条流水线式的测试流程我们称之为 pipeline。

入门教程

如何使用 CI/CD?

  • 首先需要确保有可用的 runner(如何确保呢?请看 CI/CD 入门),来运行下文提到的各种任务。
  • 在仓库的根目录下创建并编写一个 .gitlab-ci.yaml 文件,记录需要执行的各种指令,比如进行规范检查(例如PEP8)、自动打包、自动部署等。该遵循 yaml 文件的语法,可以使用 gitlab 自带的 CI lint 检查。

使用技巧

在编写 .gitlab-ci.yaml 文件的时候,有很多关键字,本文列举了一些常用&重要的关键字。

  • stages 关键字:定义了pipeline中各任务的执行顺序。 需要注意以下几点:

    • 如果两个任务对应的stage名相同,则这两个任务会并行运行

    • 一个stage成功执行完了,才能执行下一个stage(如果失败了,下一个stage将不会执行,如果想要修改该特性,可以使用when关键字,见下文)

    • 如果想要控制某一个stage在最开始,或者最后执行,可以使用.pre.post 关键字

    • 举例( 下面样例的执行顺序是: build-job1 & build-job2并行执行 -> test1 -> deploy。)

      stages:
      - build
      - test
      - deploy

      build-job1:
      stage: build
      script: echo "build-job1"

      build-job2:
      stage: build
      script: echo "build-job2"

      test1:
      stage: test
      script: echo "test"

      deploy1:
      stage: deploy
      script: echo "deploy"
      ...

  • only/except 关键字:控制任务的触发条件。

    • only关键字的默认策略是'branches', 'tags',即你提交了一个分支或者打了标签,就会触发;except 和 only 语义相反。

    • 策略的分类:

      • branches: 当你的Git Refs对应的是一个分支时触发
      • tags: 当你的Git Refs对应的是一个标签时触发
      • pushes: 当你使用git push时触发
      • merge_requests: 当你创建或者更新一个merge_requests时触发
      • ...
  • tags 关键字:指定使用哪个Runner(哪个机器)去执行任务,注意与上文only关键字的tags进行区分

  • cache关键字:指定了需要缓存的文件夹或者文件,目的是为了加快执行速度

  • artifacts关键字:和cache类似,也可以缓存文件或文件夹,不同的是,这些文件可以在Gitlab的UI界面中下载,一般可用来存储Android打包生成的apk。

  • allow_failure关键字:允许任务失败,任务失败将不会影响pipeline失败。

  • dependencies关键字:定义了任务的依赖关系,比如依赖其他的项目、库、工具、任务等。

  • variables关键字:定义局部变量(只在当前的任务中生效)

  • when关键字:可以手动修改stage原有的执行规则。一共有五个值:

    • on_success:只有前面stages的所有工作成功时才执行,这是默认值。
    • on_failure:当前面stages中任意一个jobs失败后执行
    • always:无论前面stages中jobs状态如何都执行
    • manual:手动执行
    • delayed:延迟执行
  • 更多关键字参考:https://docs.gitlab.cn/jh/ci/yaml/

完整样例

来一个完整的 .gitlab-ci.yml 例子:

复制代码
  stages:  # 定义了两个stage,先 build 后 test
    - build
    - test

  cache: # 定义 cache 缓存文件夹路径
    paths:
      - cache_dir/

  variables:  # 定义了全局变量,所有任务中的NVIDIA_GROUP变量都是 xxx
    NVIDIA_GROUP: xxx

  build-job:
    stage: build
    variables:
      DOCKER_IMAGE: $REGISTRY/$IMAGE_ID  # 专属于 build-job 的局部变量
    only:  # 当前任务只会在打 tag 和master 分支有提交时才会触发
      - tags
      - master
    tags:  # 指定当前任务在 machine1 这台机器上执行
      - machine1
    script: # 当前任务的执行脚本
      - echo "build-job is runing"
    cache:  # 当前任务的缓存文件夹
      - binaries/
    artifacts:
      paths:
        - html_doc/
    allow_failure: true  # 允许当前任务失败

  test-job:
    stage: test
    dependencies:  # 当前任务依赖 build-job 的执行结果
      - build-job
    only:  # 当前任务只在 master 分支有所提交的时候才会触发
      - master
    script:
      - echo "test-job is running"

参考资料:

相关推荐
宋均浩2 天前
# Docker 镜像瘦身实战:从 1.2G 到 80MB 的五个优化步骤
ci/cd·docker
宋均浩7 天前
# GitHub Actions 实战:从零搭建 CI/CD 流水线的 5 个核心配置
ci/cd
霸道流氓气质9 天前
GitLab CI/CD 完全指南
linux·ci/cd·gitlab
sbjdhjd9 天前
从零搭建企业级 CI/CD(下):Jenkins+GitLab+Harbor 全链路实战指南
git·servlet·ci/cd·云原生·云计算·gitlab·jenkins
糖果店的幽灵10 天前
软件测试接口测试从入门到精通:接口测试CI_CD集成
软件测试·ci/cd·接口测试
用什么都重名10 天前
Git 合并两个无共同历史的分支:从报错到解决全记录
git·gitlab
master33610 天前
GitLab (Docker) 常用命令及解决方案清单
docker·容器·gitlab
qq_3564086610 天前
GitLab 单机私有化部署文档(基于 Docker 环境)
docker·gitlab
平头老王10 天前
CI/CD流水线设计 — 第1章:常见误区
ci/cd·自动化·devops·持续部署·持续集成
星落zx11 天前
在CI/CD流水线里接入多模型自动Code Review,踩坑与方案分享
人工智能·ci/cd·代码复审