gitlab之配置文件.gitlab-ci.yml

自动化部署給我们带来的好处

自动化部署的好处体现在几个方面

1.提高前端的开发效率和开发测试之间的协调效率

Before

如果按照传统的流程，在项目上线前的测试阶段，前端同学修复bug之后，要手动把代码部署之后。才能通知测试同学在测试环境进行测试。

这会造成几个问题：本身手动部署服务的工作是比较繁琐的，占用了开发时间。同时开发-测试之间的环节的耦合问题，则会增加团队沟通成本。

After

通过gitlab-ci，前端开发在提交代码之后就不用管了，ci流程会自动部署到测试或集成环境的服务器。很大程度上节约了开发的时间。

同时，因为开发和测试人员可以共用gitlab里的pipeline界面, 测试同学能够随时把握代码部署的情况，同时还可以通过交互界面手动启动pipeline，自己去部署测试，从而节约和开发之间的沟通时间。

2.从更细的粒度把握代码质量

我们可以把eslint或其他的代码检查加到pipeline流程中，每当团队成员提交和合并一次，pipeline都会触发一次并对代码做一次全面检测，这样就从一个更细的粒度上控制代码质量了。

1.Pipeline & Job

Pipeline是Gitlab根据项目的.gitlab-ci.yml文件执行的流程，它由许多个任务节点组成, 而这些Pipeline上的每一个任务节点，都是一个独立的Job

Job在YML中的配置我们将会在下面介绍，现在需要知道的是：每个Job都会配置一个stage属性，来表示这个Job所处的阶段。

gitlab-ci的运行机制, 在项目根目录下配置.gitlab-ci.yml文件, 控制ci流程的不同阶段, 一般会包含

• install  安装
• eslint  检查
• build  编译
• deploy 部署

先看示例:

stages:  # 定义任务执行阶段
  - build  # 编译
  - deploy  # 部署

cache:  # 设置缓存, 默认一次任务完成, 会将产物进行删除
  key: module-cache  # 设置缓存键
  paths:  # 需要缓存的路径
    - node_modules
    - build

build:
  stage: build  # 当前所属阶段
  tags:  # 对应gitlab-runner中注册的tag(支持多个, 匹配任务 可以找到对应runner)
    - docker-vue
    - vue
  only:  # 限制指定分支,执行
    - test
    - master
  script:  # 执行shell命令
    - cd ${CI_PROJECT_DIR}
    - npm install
    - npm run build
  artifacts:  # 生成制品并上传, gitlab中可供下载
    paths:
      - dist/

delopy-test:
  stage: deploy
  tags:
    - docker-vue
    - vue
  only:
    - test
  script:
    - rm -rf /data/www/docker-vue-test/*
    - cp -rf ${CI_PROJECT_DIR}/dist/* /data/www/docker-vue-test

deploy-prod:  

  stage: deploy

  tags:

    - docker-vue

  only:

    - master

  script:  # 上线执行命令, 远程同步代码

    - rsync -avzH -e 'ssh -p 2222' --delete ${CI_PROJECT_DIR}/dist/ root@xx.xx.xx.xx:/opt/docker-vue/

触发时机: 每当你push/merge, gitlab-ci都会检查项目下有没有.gitlab-ci.yml文件,存在则执行里面的任务

不同push/merge所触发的CI流程不会互相影响，也就是说，你的一次push引发的CI流程并不会因为接下来另一位同事的push而阻断，它们是互不影响的。这一个特点方便让测试同学根据不同版本进行测试。

注意点:

　　1. 部署的时候 可以使用scp 将本地代码远程拷贝到云服务

因为这一命令需要输入密码，所以通过 sshpass 命令携带密码再执行scp：

sshpass -p $PASSWORD scp -r ./build $CUSTOM_USERNAME@$CUSTOM_IP:/var/www/html

这里说明一下，Gitlab有自定义变量的功能，例如我们觉得直接在YML中写入密码/账号等信息不太好，那么可以通过美元符号$写入一个预定义的变量，然后在Gitlab面板上输入它

　　当然也可以只用免密认证的方式, 这样就不需要输入密码了

重要参数:

　　cache:

用作缓存,

为什么要做缓存呢？当然是为了重复运行pipeline的时候不会重复安装全部node_modules的包，从而减少pipeline的时间，提高pipeline的性能。

但是，这并不是cache关键字唯一的功能！

在介绍cache的另外一个功能之前，我要先说一下gitlab-ci的一个优点“恶心人”的特点：

它在运行下一个Job的时候，会默认把前一个Job新增的资源删除得干干静静

没错，也就是说，我们上面bulid阶段编译生成的包，会在deploy阶段运行前被默认删除！

而cache的作用就在这里体现出来了：如果我们把bulid生产的包的路径添加到cache里面，虽然gitlab还是会删除bulid目录，但是因为在删除前我们已经重新上传了cache，并且在下个Job运行时又把cache给pull下来，那么这个时候就可以实现在下一个Job里面使用前一个Job的资源了

总而言之，cache的功能体现在两点：

• 在不同pipeline之间重用资源

• 在同一pipeline的不同Job之间重用资源

虽然cache会缓存旧的包，但我们并不用担心使用到旧的资源，因为npm install还是会如期运行，并检查package.json是否有更新，npm build的时候，生成的build资源包也会覆盖cache,并且在当前Job运行结束时，作为**"新的cache"**上传

artifacts关键字

这个关键字的作用是：将生成的资源作为pipeline运行成功的附件上传，并在gitlab交互界面上提供下载

例如我们新增以下YML

Build-job:
  stage: build
  script:
  - 'npm run build'
  artifacts:
    name: 'bundle'
    paths:
      - build/

only/except

这两个关键字后面跟的值是tag或者分支名的列表。

故名思义

• only的作用是指定当前Job仅仅只在某些tag或者branch上触发

• 而except的作用是当前Job不在某些tag或者branch上触发

job:
  # use regexp
  only:
    - /^issue-.*$/
    - develop
    - release

test:
  stage: test
  before_script:
    - echo "before script in test..."
  script:
    - echo "script in test..."
    - error
  tags:
    - docker_in_docker_demo
  allow_failure: true
  parallel: 5

allow_failure

allow_failure是允许当前作业失败，这个在比如测试脚本开发的过程中等情况下是非常有用的，比如脚本还没有调试稳定，失败不表示产品有问题的时候就可以设置当前作业允许失败

值为true/false, 表示当前Job是否允许允许失败。

• 默认是false,也就是如果当前Job因为报错而失败，则当前pipeline停止

• 如果是true，则即使当前Job失败，pipeline也会继续运行下去。

job1:
  stage: test
  script:
    - execute_script_that_will_fail
  allow_failure: true

retry

顾名思义，指明的是当前Job的失败重试次数的上限。

但是这个值只能在0 ～2之间，也就是重试次数最多为2次，包括第一次运行在内，Job最多自动运行3次

verify:
  stage: verify
  script: error
  retry: 2
  tags:
    - docker_in_docker_demo

此外，retry还可以通过max指定最大次数，通过when指定重试的条件，when可选的值如下：

always：在发生任何情况下重试（默认）
unknown_failure：当失败原因未知时
script_failure：脚本失败时重试
api_failure：API失败重试
stuck_or_timeout_failure：作业卡住或超时
runner_system_failure：运行系统发生故障
missing_dependency_failure：如果依赖丢失
runner_unsupported：Runner不支持
stale_schedule：无法执行延迟的作业
job_execution_timeout：脚本超出了为作业设置的最大执行时间
archived_failure：作业已存档且无法运行
unmet_prerequisites：作业未能完成先决条件任务
scheduler_failure：调度程序未能将作业分配给运行scheduler_failure
data_integrity_failure：检测到结构完整性问题

verify-2:
  stage: verify
  script: error
  retry:
    max: 2
    when:
      - script_failure
  tags:
    - docker_in_docker_demo
  timeout: 3s

timeout

配置超时时间，超过时间判定为失败

Job:
  script: rspec
  timeout: 3h 30m

When

表示当前Job在何种状态下运行，它可设置为3个值

• on_success: 仅当先前pipeline中的所有Job都成功（或因为已标记，被视为成功allow_failure）时才执行当前Job 。这是默认值。

• on_failure: 仅当至少一个先前阶段的Job失败时才执行当前Job。

• always: 执行当前Job，而不管先前pipeline的Job状态如何。

• manual:  手动执行作业
• delayed: 延迟执行作业

deploy:
  stage: deploy
  script:
    - echo "script in deploy..."
  tags:
    - docker_in_docker_demo
  when: manual

deplayed可以配置start_in参数使用，设置延迟执行，如下为延迟10秒执行当前任务

release:
  stage: release
  script:
    - echo "script in release..."
  after_script:
    - echo "after in release..."
  tags:
    - docker_in_docker_demo
  when: delayed
  start_in: "10"

timeout:

设置作业超时时间

设置时间的格式比如：
1h 10m # 一个小时10分钟
10m 20s # 10分钟20秒
30s # 30秒
如下：设置超时时间为3s

verify-2:
  stage: verify
  script: error
  retry:
    max: 2
    when:
      - script_failure
  tags:
    - docker_in_docker_demo
  timeout: 3s

parallel

parallel可以指定一个任务并行运行多次
如下，表示当前任务并行运行5次

test:
  stage: test
  before_script:
    - echo "before script in test..."
  script:
    - echo "script in test..."
    - error
  tags:
    - docker_in_docker_demo
  allow_failure: true
  parallel: 5

dependencies: 定义job依赖关系, 这样他们可以互相传递artifacts

注意：所有之前的stages都是默认设置通过。

如果要使用此功能，应该在上下文的job中定义dependencies，并且列出之前都已经通过的jobs和可下载的artifacts。你只能在当前执行的stages前定义jobs。你如果在当前stages或者后续的stages中定义了jobs，它将会报错。可以通过定义一个空数组是当前job跳过下载artifacts。

代码回滚:

一般是需要定义一个environment的参数,在部署 > 环境中可以看到对应的环境变量

示例:

delopy-test:
  stage: deploy
  tags:
    - docker-vue
    - vue
  only:
    - test
  script:
    - rm -rf /data/www/docker-vue-test/*
    - cp -rf dist/* /data/www/docker-vue-test
  environment:
    name: docker-vue-test

参考文件:

• 　　https://zhuanlan.zhihu.com/p/105945748
• 文件配置详解: https://meigit.readthedocs.io/en/latest/gitlab_ci_.gitlab-ci.yml_detail.html