GitLab CI

1、为什么要用gitlab

GitHub提供公开免费的服务,但是默认所有代码是公开的(除非您付费)。GitLab提供类似github的服务,它的优势是:

  • 在自己的服务器上部署gitlab

  • 方便的权限控制

  • 自动化构建部署CI/CD

2、gitlab CI相关概念

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

1、Gitlab-CI

Gitlab-CI是GitLab Continuous Integration(Gitlab持续集成)的简称。只要在项目仓库的根目录添加.gitlab-ci.yml文件,并且配置了Gitlab-Runner(运行器),那么每一次合并请求或者push都会触发CI。

2、Gitlab-runner

Gitlab-runner是.gitlab-ci.yml脚本的运行器,Gitlab-runner一般安装在单独的服务器上(不需要和Gitlab安装在同一台机器上,注册)

3、Pipelines

Pipelines是定义于.gitlab-ci.yml中的不同阶段的不同任务。stages有几个值,Pipelines就有几个,一般

Pipelines三个阶段

GitLab CI运行流程

![alt](../assets/image/201904301805.jpg)

#镜像,如node:latest表示使用最新的node版本
image: node:12.6.0

variables:
    # 处理ssh连接服务器的报错Hostkeyverification failed
    SSH_OPTS: "-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
    RSYNC_OPTS: "-r --exclude=.git --force --delay-updates"

stages:
    - build
    - deploy

# 缓存文件
# &用来建立锚点,*用来引用锚点,<<表示合并到当前数据
.cache: &cache #设置一个锚点
    # 以项目路径-分支名为key缓存
    key: "${CI_PROJECT_PATH}-${CI_COMMIT_REF_SLUG}"
    # 在script执行ls -la可以看到所有生成的文件
    # 且只能使用本地工作副本中的路径
    paths:
    - ci_cache/
    - node_modules/

#构建阶段
job1:
    stage: build
    cache:
        #引用cache并合并到当前数据
        <<: *cache
    script:
    #创建目录./ci_cache
    #缓存yarn的依赖文件,避免每次都从仓库里拉取依赖包
    - 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部分。例如:

job_name:
    script: "echo this is a test"

全局属性

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

解释:

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

  • services 定义构建期间使用的服务列表(例如,[1]services:docker:dind表示在Docker中使用Docker,简称Docker In Docker,即dind[2]例如services:postgres:9.3表示使用pg数据库)

  • 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_successon_failurealwaysmanual,默认为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: node:latest

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

# 仅在develop环境执行
job1:
    stage: build
    script:
        - "echo this is a test"
    only:
        - develop
job2:
    stage: deploy
    script:
        - "echo this is a test"
    only:
        - develop

# 仅在master环境执行
job3:
    stage: build
    script:
        - "echo this is a test"
    only:
        - master
job4:
    stage: deploy
    script:
        - "echo this is a test"
    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的界面上设置私有变量,来调用敏感信息。查看配置教程

alt

alt

参考:

[1] GitLab文档

[2] GitLab CI/CD 常见属性

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

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效果