.gitlab-ci.yml语法

系统运维 .gitlab-ci.yml

.gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作，这个文件位于仓库的根目录。

当有新内容 push 到仓库，或者有代码合并后， GitLab 会查找是否有 .gitlab-ci.yml 文件，如果文件存在， Runners 将会根据该文件的内容开始 build 本次 commit 。

.gitlab-ci.yml 使用 YAML 语法， 你需要格外注意缩进格式，要用空格来缩进，不能用 tabs 来缩进。

Stages 表示构建阶段，说白了就是上面提到的流程。默认有3个 stages ： build , test , deploy 。我们可以在一次 Pipeline 中定义多个 Stages ，这些 Stages 会有以下特点：

所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始

只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功

如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。我们可以在 Stages 里面定义多个 Jobs ，这些 Jobs 会有以下特点：

1、相同 Stage 中的 Jobs 会并行执行

2、相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功

3、如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

任务中必须得有 script 部分。

# 定义 stages（阶段）。任务将按此顺序执行。

stages:

- build

- test

- deploy

# 定义 job（任务）

job1:

  stage: test

  tags:

  - XX #只有标签为XX的runner才会执行这个任务

  only:

  - dev #只有dev分支提交代码才会执行这个任务。也可以是分支名称或触发器名称

  - /^future-.*$/ #正则表达式，只有future-开头的分支才会执行

  script:

  - echo I am job1

  - echo I am in test stage

# 定义 job

job2:

  stage: test #如果此处没有定义stage，其默认也是test

  only:

  - master #只有master分支提交代码才会执行这个任务

  script:

  - echo I am job2

  - echo I am in test stage

  allow_failure: true #允许失败，即不影响下步构建

# 定义 job

job3:

  stage: build

  except:

  - dev #除了dev分支，其它分支提交代码都会执行这个任务

  script:

  - echo I am job3

  - echo I am in build stage

# 定义 job

.job4: #对于临时不想执行的job，可以选择在前面加个.，这样就会跳过此步任务，否则你除了要注释掉这个job4外，还需要注释上面为deploy的stage

    stage: deploy

    script:

    - echo I am job4

# 模板，相当于公用函数，有重复任务时很有用

.job_template: &job_definition # 创建一个锚，\'job_definition\'

  image: ruby:2.1

  services:

  - postgres

  - Redis

test1:

  <<: *job_definition # 利用锚\'job_definition\'来合并

  script:

  - test1 project

test2:

  <<: *job_definition # 利用锚\'job_definition\'来合并

  script:

  - test2 project

#下面几个都相当于全局变量，都可以添加到具体job中，这时会被子job的覆盖

before_script:

- echo 每个job之前都会执行

- export MVN_HOME

- export JAVA_HOME

- java -version

- sh /home/gitlab-runner/kill.sh

after_script:

- echo 每个job之后都会执行

variables: #变量

  DATABASE_URL: postgres://postgres@postgres/my_database #在job中可以用${DATABASE_URL}来使用这个变量。常用的预定义变量有CI_COMMIT_REF_NAME（项目所在的分支或标签名称），CI_JOB_NAME（任务名称），          CI_JOB_STAGE（任务阶段）

  GIT_STRATEGY: none #GIT策略，定义拉取代码的方式，有3种：clone/fetch/none，默认为clone，速度最慢，每步job都会重新clone一次代码。我们一般将它设置为none，在具体任务里设置为fetch就可以满足需求，毕竟不是每步都需要新代码，那也不符合我们测试的流程

cache: #缓存

  #因为缓存为不同管道和任务间共享，可能会覆盖，所以有时需要设置key

  key: ${CI_COMMIT_REF_NAME} # 启用每分支缓存。

  #key: $CI_JOB_NAME/$CI_COMMIT_REF_NAME # 启用每个任务和每个分支缓存。需要注意的是，如果是在windows中运行这个脚本，需要把$换成%

  untracked: true #缓存所有Git未跟踪的文件

  paths: #以下2个文件夹会被缓存起来，下次构建会解压出来

  - node_modules/

  - dist/

如果你的 commit 信息包涵 [ci skip] 或者 [skip ci] ，不论大小写，这个 commit 将会被创建，但是 job 会被跳过

版本回滚

stages:

-  build

-  deploy

build_job:

  stage: build

  tags: 

  - test1

  script:

  - echo this is a test !

dev_job:

  stage: deploy

  tags: 

  - test1

  environment: 

    name: v2

    url:  http://www.test.com

  script:

  - echo this is a deploy !

environment: 是配置在deploy这个stage里面的，用于后面Environments可以做版本回滚。

红色部分是URL，回滚的时候点击即可直接跳转到指定位置。

stages:

-  build

-  deploy

build_job:

  stage: build

  tags: 

  - test1

  script:

  - echo this is a test !

dev_job:

  stage: deploy

  tags: 

  - test1

  environment: 

    name: v2

    url:  www.baidu.com

  script:

  - echo this is a deploy !

  when: always #不管前面几步成功与否，永远会执行这一步。它有几个值：on_success （默认值）\\on_failure\\always\\manual（手动执行）

每次提交代码就会自动触发构建并自动发布，production的构建发布需要手动点击按钮，这个是when: manual实现的。

when 用于实现在出现故障或运行失败时运行的作业。

when 可以设置为以下值之一：

on_success - 只有当前一个阶段的所有工作成功时才执行工作。这是默认值。

on_failure - 仅当前一个阶段的至少一个作业发生故障时才执行作业。

always - 无论前一阶段的工作状况如何，继续执行工作。

manual - 手动执行作业（在GitLab 8.10中添加）

所有jobs的执行环境为指定的docker image所生成的container，每个job都会生成一个container并且在job结束后立即销毁。

Pull policies

当你使用docker 或 docker+machine executors时，你可以通过设置pull_policy来决定Runner如何pull docker image。pull_policy有三种值：

always —— Runner始终从远程pull docker image。

if-not-present —— Runner会首先检查本地是否有该image，如果有则用本地的，如果没有则从远程拉取。

never —— Runner始终使用本地的image。