了解GitLab CI

1、为什么要用gitlab

GitHub 是一项公开可用的免费服务,它要求所有代码(除非您有付费帐户)公开。GitLab是一种类似github的服务,组织可以使用它来提供git存储库的内部管理。 它是一个自我托管的Git-repository管理系统,可以保持用户代码的私密性,并且可以轻松地部署代码的更改。

2、gitlab CI相关概念

gitlab-ci.yml是用来配置CI在我们的项目中做些什么工作,它位于项目的根目录,定义项目如何构建。(gitlab-ci.yml是一个YAML文件,所以必须要格外注意缩进,使用空格,而不是tabs。)

1、Gitlab-CI

Gitlab-CI是GitLab Continuous Integration(Gitlab持续集成)的简称。从Gitlab的8.0版本开始,gitlab就全面集成了Gitlab-CI,并且对所有项目默认开启。只要在项目仓库的根目录添加.gitlab-ci.yml文件,并且配置了Runner(运行器),那么每一次合并请求(MR)或者push都会触发CI pipeline。

2、Gitlab-runner

Gitlab-runner是.gitlab-ci.yml脚本的运行器,Gitlab-runner是基于Gitlab-CI的API进行构建的相互隔离的机器(或虚拟机),GitLab Runner 不需要和Gitlab安装在同一台机器上。

3、Pipelines

Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。

可以把Pipelines理解为流水线,流水线包含有多个阶段(stages),每个阶段包含有一个或多个工序(jobs),比如先购料、组装、测试、包装再上线销售,每一次push或者MR都要经过流水线之后才可以合格出厂。而.gitlab-ci.yml正是定义了这条流水线有哪些阶段,每个阶段要做什么事。

GitLab CI运行流程

image: ''  #镜像

variables:
  SSH_OPTS: "-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
  RSYNC_OPTS: "-r --exclude=.git --force --delay-updates"

stages:
  - build
  - deploy

.cache: &cache #设置一个锚点
  key: "${CI_PROJECT_PATH}-${CI_COMMIT_REF_SLUG}"
  paths:
    - ci_cache/

#构建阶段
job1:
  stage: build
  cache:
      #引用cache并合并到当前数据
      <<: *cache
  script:
    #创建目录./ci_cache
    #把缓存提取到外部的文件里面,处理多环境缓存的问题
    - mkdir -p ./ci_cache
    #设置缓存目录为./ci_cache
    - yarn config set cache-folder ./ci_cache
    #打印出当前的yarn全局缓存位置
    - yarn cache dir
    # 处理sass-binary-site安装慢的问题
    - yarn config set sass-binary-site http://npm.taobao.org/mirrors/node-sass
    - yarn config set registry https://registry.npm.taobao.org -g
    - yarn install
    - npm run build:master
  # 指定附加到job的文件和目录的列表
  artifacts:
    paths:
      - dist/
  only:
    #仅在master分支执行
    - master

#部署阶段
job2:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  cache: {}
  script:
    #拷贝文件dist到服务器10.50.30.15上的指定文件上,完成部署
    - rsync $RSYNC_OPTS -e "ssh $SSH_OPTS" ./dist 10.50.30.15:/srv/my-project/
  only:
    #仅在master分支执行
    - master
  #设置手动开始job
  when: manual

如上,&用来建立锚点,*用来引用锚点,«表示合并到当前数据

GitLab CI字段说明

gitlab-ci.yml定义了一系列带有约束说明的job,以任务名开始且至少要包含script部分。例如最简单的一个gitlab-ci.yml文件:

job_name:
    script: "echo this is a test"

全局属性

关键字 是否必须 描述
image 用于docker镜像
services 用于docker服务
stages 定义构建阶段
before_script 定义在每个job之前运行的命令
after_script 定义在每个job之后运行的命令
variable 定义构建变量
cache 定义一组文件列表,可在后续运行中使用

解释:

  • image和services 这两个关键字允许使用一个自定义的Docker镜像和一系列的服务,并且可以用于整个job周期。

  • stages 定义可以被job调用的stages,stages中的元素顺序决定了对应job的执行顺序。

  • before_script 定义所有job之前运行的命令,包括deploy(部署)的jobs。

  • after_script 定义所有job之后运行的命令,它必须是一个数组或者是多行字符串。

  • variable GItLab CI 允许在.gitlab-ci.yml文件中添加变量,并在job环境中起作用(存储在git仓库中,最好是存储项目的非敏感配置)。这些变量可以被后续的命令和脚本使用。服务容器也可以使用YAML中定义的变量,因此我们可以很好的调控服务容器。变量也可以定义成job level(即在job中定义变量,仅在job中生效)。

  • cache 如果cache定义在jobs的作用域之外,那么它就是全局缓存,所有jobs都可以使用该缓存(job中优先级高于全局的)。

job的属性

关键字 是否必须 描述
script Runner执行的命令或脚本
stage 定义job stage(默认:test)
only 定义一列git分支,并为其创建job
except 定义一列git分支,不创建job
tags 定义一列tags,用来指定选择哪个Runner(同时Runner也要设置tags)
allow_failure 允许job失败。失败的job不影响commit状态
when 定义何时开始job。可以是on_success,on_failure,always或者manual
artifacts 指定job成功后应附加到job的文件和目录的列表
dependencies 定义job依赖关系,这样他们就可以互相传递artifacts
environment 定义此作业完成部署的环境名称
coverage 定义给定作业的代码覆盖率设置
image 所使用的docker镜像
services 所使用的docker服务
variables 定义job级别的变量
cache 定义应在后续运行之间缓存的文件列表
before_script 重写一组在作业前执行的命令
after_script 重写一组在作业后执行的命令

解释:

  • script 定义Runner执行的yaml脚本,当命令中包含特殊字符(如冒号:)时,script需要被包在双引号中

  • stage 将当前job与stages关联

  • only和except 用分支策略来限制jobs构建。如only定义哪些分支和标签的git项目将会被job执行,except定义哪些分支和标签的git项目将不会被job执行(only和except可以使用正则表达式)。

  • tags 指定特殊的Runners来运行jobs(Runner需要设置该标签)

  • allow_failure 值为true或false,设置jobs失败是否继续commit(例如设置allow_failure: true表示当该job失败后继续执行下一个stage)

  • when 值可以为on_success、on_failure、always、manual,默认为on_success表示只有前面stages的所有工作成功时才执行。on_failure表示前面stages中任意一个jobs失败后执行。always表示无论前面stages中jobs状态如何都执行。manual表示手动执行。

  • artifacts 用于指定job成功后应附加到job的文件和目录的列表。只能使用项目工作间内的文件或目录路径。

  • dependencies 与artifacts一起使用,并允许定义在不同jobs之间传递artifacts。如果要使用此功能,应该在上下文的job中定义dependencies,并且列出之前都已经通过的jobs和可下载的artifacts。

  • environment 定义job部署到特殊的环境中。如果指定了environment,并且没有该名称下的环境,则会自动创建新环境。

  • coverage 仅支持正则表达式,用来测量代码覆盖率

GitLab CI疑问

GitLab CI如何实现分环境部署

GitLab CI根据stages运行(一般有build、test、deploy三个阶段),每个job通过下面的stage与stages关联,然后通过only限制各个环节执行的内容,如下示例:

image: ''

# 定义两个阶段
stages:
    - build   #先执行
    - deploy  #后执行

# 仅在develop环境执行
job1:
    stage: build
    script:
        - excute something
    only:
        - develop

job2:
    stage: deploy
    script:
        - excute something
    only:
        - develop

# 仅在master环境执行
job3:
    stage: build
    script:
        - excute something
    only:
        - master

job4:
    stage: deploy
    script:
        - excute something
    only:
        - master

如上配置,每次push或者merge的时候,都会触发GitLab CI执行,先查看stages(如上有build、deploy两个阶段),然后,Gitlab-runner执行(通过job的only属性控制在不同分支执行不同的内容)

GitLab CI中stages的执行顺序

stages中的元素顺序决定了对应job的执行顺序,所以执行的顺序为build、test、deploy。且相同stages的job是并行执行的,且下一个stage的job会在前一个stage的job成功后开始执行。

stages:
    - build   #先执行
    - test    #后执行
    - deploy  #最后执行

如上,所有的stage为build的job是并行执行的。所有build的jobs执行成功后,test的jobs才会开始并行执行。所有test的jobs执行成功,deploy的jobs才会开始并行执行。所有的deploy的jobs执行成功,commit才会标记为success。任何一个前置的jobs失败了,commit会标记为failed并且下一个stages的jobs都不会执行。

如果.gitlab-ci.yml中没有定义stages,那么job's stages 会默认定义为 build,test 和 deploy。如果一个job没有指定stage,那么这个任务会分配到test stage。

GitLab CI中定义私有变量

.gitlab-ci.yml一般通过在GitLab的界面上设置私有变量,来调用敏感信息。查看配置教程

GitLab CI中缓存设置

1、常见缓存设置

缓存binaries和.config中的所有文件

job_test:
    script: test
    cache:
        paths:
            - binaries/
            - .config

缓存git中没有被跟踪的文件

job_test:
    script: test
    cache:
        untracked: true

缓存binaries下没有被git跟踪的文件

job_test:
    script: test
    cache:
        untracked: true
        paths:
            - binaries/

2、缓存key设置

缓存key可以为任何的预定义变量,查看预定义变量

缓存每个job

cache:
    key: "$CI_JOB_NAME"
    untracked: true

缓存每个分支

cache:
    key: "$CI_COMMIT_REF_NAME"
    untracked: true

缓存每个job且每个分支

cache:
    key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
    untracked: true

如果使用window来跑脚本,需要使用%代替$,如上最后的代码的key需要替换为%CI_JOB_NAME%/%CI_COMMIT_REF_NAME%

参考:

[1] GitLab文档

[1] GitLab CI/CD 常见属性

[3] gitlab ci/cd .gitlab-ci.yml配置任务详解

[4] GitLab CI/CD Pipeline Configuration Reference

[5] coverage的作用和用法

Author:tenado
CeateTime:2019-04-18
Link:https://www.kelede.win/posts/GitLab-CI%E7%AE%80%E5%8D%95%E4%BB%8B%E7%BB%8D/
License:本站博文无特别声明均为原创,转载请保留原文链接及作者
Previous:React Hook初步理解 Next:Vue实现SSR效果