gitlab-ci配置详解(二)

jobs(任务)

.gitlab-ci.yml容许用户建立无数多个任务.可是每一个任务必须有一个独一无二的名字，但不能是如下保留字.一个任务是由一列参数定义的，来决定任务的工做内容和行为.

job_name:
  # 要跑的脚本或命令列表
  script:
    - rake spec
    - coverage
  # pipelines阶段
  stage: test
  # 只针对哪一个分支
  only:
    - master
  # 除了哪一个分支之外
  except:
    - develop
  # 指定哪些runner适用该job
  tags:
    - ruby
    - postgres
  # 是否容错
  allow_failure: true

关键字	是否必须	描述
script	必须	定义Runner须要执行的脚本或命令
image	非必须	须要使用的docker镜像，请查阅该文档
services	非必须	定义了所需的docker服务，请查阅该文档
stage	非必须	定义了工做的场景阶段,默认是test
type	非必须	stage的别名，不同意使用
variables	非必须	在job级别上定义的变量
only	非必须	定义哪些git引用（分支）适用该job
except	非必须	定义了哪些git引用(分支)不适用该job
tags	非必须	定义了哪些runner适用该job（runner在建立时会要求用户输入标签名来表明该runner）
allow_failure	非必须	容许任务失败，可是若是失败，将不会改变提交状态
when	非必须	定义job何时能被执行，能够是on_success,on_failure,always或者manual
dependencies	非必须	定义了该job依赖哪个job，若是设置该项，你能够经过artifacts设置
artifacts	非必须	所谓工件。。就是在依赖项之间传递的东西，相似cache，但原理与cache不一样
cache	非必须	定义须要被缓存的文件、文件夹列表
before_script	非必须	覆盖在根元素上定义的before_script
after_script	非必须	覆盖在根元素上定义的after_script
environment	非必须	定义让job完成部署的环境名称
retry	非必须	定义job失败后的自动重试次数

script

script是一段由Runner执行的shell脚本，例如：

job:
  script: "bundle exec rspec"

这个参数也可使用数组包涵好几条命令：

job:
  script:
    - uname -a
    - bundle exec rspec

有些时候，script命令须要被单引号或者双引号所包裹。举个例子，命令中包涵冒号的时候，该命令须要被引号所包裹，这样YAML解析器才知道该命令语句不是“key: value”语法的一部分。当命令中包涵如下字符时须要注意打引号:: { } [ ] , & * # ? | - < > = ! % @ `

stage

stage指定一组job在不一样场景阶段执行。在相同stage下的job(任务)将会被并行的执行。关于stage更多用法的描述，请查看stages

only and except(简易说明)

only和except两个参数说明了job何时将会被建立:

1. only定义了job须要执行的所在分支或者标签
2. except定义了job不会执行的所在分支或者标签

如下是这两个参数的几条用法规则：

1. only和except若是都存在在一个job声明中，则所需引用将会被only和except所定义的分支过滤.
2. only和except容许使用正则
3. only和except容许使用指定仓库地址，可是不forks仓库

此外，only和except容许使用如下一些特殊关键字：

值	描述
branches	当一个分支被push上来
tags	当一个打了tag的分支被push上来
api	当一个pipline被piplines api所触发调起，详见piplines api
external	当使用了GitLab之外的CI服务
pipelines	针对多项目触发器而言，当使用CI_JOB_TOKEN并使用gitlab所提供的api建立多个pipelines的时候
pushes	当pipeline被用户的git push操做所触发的时候
schedules	针对预约好的pipline而言（每日构建一类~，具体请看连接）
triggers	用token建立piplines的时候
web	在GitLab页面上Pipelines标签页下，你按了run pipline的时候

下面的例子，job将会只在issue-开头的refs下执行，反之则其余全部分支被跳过：

job:
  # use regexp
  only:
    - /^issue-.*$/
  # use special keyword
  except:
    - branches

在这个例子中，job只会在打了tag的分支，或者被api所触发，或者每日构建任务上运行，

job:
  # use special keywords
  only:
    - tags
    - triggers
    - schedules

若是指定了仓库路径，该任务将会在指定仓库路径被push或者其余操做的时候被运行，可是不会forks,(注，仓库路径只能是父仓库，也就是你指定了仓库里远程仓库的那个仓库地址~)

job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce

上面这个例子的job将会在父仓库gitlab-org/gitlab-ce的非master分支有提交时运行.有点拗口

only and except(复杂版本)

从GitLab10引入的
这是个测试特性，可能在没有通知的状况下更改该特性

自从GitLab10.0之后，咱们能够配置更加复杂的job策略。

GitLab如今同时支持简单和复杂的job策略定义。如今咱们甚至可使用数组或者对象的配置方案来配置咱们的job策略。

在复杂的定义下，如今有两个参数可用，refs和kubernetes.refs的策略等同于设置通常的only/except配置，可是kubernetes只有一个可选值，active.

请看下面的例子，该job只会在计划被触发时或者master分支被push时触发，而且先决条件是kubernetes服务是活跃的（你启用了kubernetes服务做为执行器，相关请看gitlab ci runner的文档，ce用户通常用求不到）。

job:
  only:
    refs:
      - master
      - schedules
    kubernetes: active

variables

在job级别容许用户定义变量，他的工做方式和全局级别的变量定义相同，不过该变量做用域仅限于当前job。

当您再job级别使用了variables定义变量，它将会覆盖YAML设置的全局变量和预约义的变量，若是你要在job级别屏蔽全局定义的变量，你能够用空对象覆盖它：

job_name:
    variables: {}

job变量的优先级在variables文档中有所阐述

tags

tags这个参数是用来选择容许哪些runners来执行该jub的。

当你初始化Runner并注册一个Runner的时候，你被要求为Runner指定一个或多个标签，例如个人一个Runner被注册为test1。

job:
    tags:
        - test1
        - ruby

上面的声明将会保证该job将会被标签上有test1和ruby的runner所执行。若是没有就不执行

allow_failure

allow_failure被用于当你想容许job失败而不阻塞剩下的CI套件执行的时候，失败的job不会影响到commit状态(pipelines执行完会在commit上标记失败或成功状态，可是不会阻止commit提交)

当allow_failure为true,而且job失败了，pipline将会置绿或者置成功显示，可是你会在commit页面或者job页面看到一条“CI build passed with warnings”的警告信息哈。这样用户就能注意到失败并采起其余措施。

在下面的例子中，job1和job2将会并行执行（事实告诉咱们其实仍是顺序执行）,不过若是job1失败了，整个pipeline不会中止，而且会流转到下一个场景阶段继续执行：

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

job2:
  stage: test
  script:
  - execute_script_that_will_succeed

job3:
  stage: deploy
  script:
  - deploy_to_staging

上面的例子实测，job1显示警告，job2经过，job3经过

when

when参数是肯定该job在失败或者没失败的时候执行不执行的参数。

when支持如下几个值之一:

1. on_success 只有在以前场景执行的全部做业成功的时候才执行当前job，这个就是默认值，咱们用最小配置的时候他默认就是这个值，因此失败的时候pipeline会中止执行后续任务
2. on_failure 只有在以前场景执行的任务中至少有一个失败的时候才执行
3. always 无论以前场景阶段的状态，老是执行
4. manual ~手动执行job的时候触发（webui上点的）。请阅读manual action

下面是例子:

stages:
- build
- cleanup_build
- test
- deploy
- cleanup

build_job:
  stage: build
  script:
  - make build

cleanup_build_job:
  stage: cleanup_build
  script:
  - cleanup build when failed
  when: on_failure

test_job:
  stage: test
  script:
  - make test

deploy_job:
  stage: deploy
  script:
  - make deploy
  when: manual

cleanup_job:
  stage: cleanup
  script:
  - cleanup after jobs
  when: always

上面的例子将会:

1. 只有在build_job失败的时候执行cleanup_build_job
2. 在pipeline最后一步，无论前面是失败或者成功，执行cleanup_job
3. 容许你在GitLabUI上手动执行deploy_job

manual actions

自GitLab8.10引入，Blocking manual actions自GitLab9.0引入，Protected actions自GitLab9.2引入

手动操做是一类特殊的job类型，该类型不会自定执行；只有用户在gitlab ui上点击执行按钮的时候才会被触发。手动执行操做能够在pipeline页面，build场景，environment页面，和deployment页面上找到按钮按

其中一个场景就是，你在生产部署页面摁部署按钮。

阅读更多，请移步environments documentation.

手动操做能够是可选的或者是阻塞的。阻塞的手动操做将会阻塞定义了手动操做的场景步骤。这个时候你能够看到pipline页面上有个play按钮，若是你按play按钮，能够恢复pipeline的执行（一个类比，手动触发部署行为）。

当一个pipeline被阻塞了，那么即便pipeline commit状态为succeeds，你也不能执行merge操做（不懂先看下面一段话，当你设置不容许失败的时候，整个pipline被阻塞，在提交分支merge的时候，pipeline因为状态为manual，不能merge），被阻塞的pipelines也有一个特别的状态，叫作manual

手动操做默认是非阻塞的，若是你想让手动操做阻塞，你必须为job设置allow_failure:false（不设置默认为true，没法阻塞pipeline）

可选操做的状态是没法改变pipeline总体状态的，只有阻塞操做能够

手动操做被认为是白箱操做，因此当用户想要触发操做的时候，是有权限保护的。换句话说，用户若是想要触发手动操做，你必须有合并到当前分支的权限

environment

注意：

• 自gitLab8.9引进
• 你能够从documentation about environments获取更多信息和例子

environment是用于定义一个job(做业)部署到某个具名的环境，若是environment被指定，可是没有叫该名的environment存在，一个新的environment将会被自动建立(实际上这个环境并非指向真实环境，设置这条会将相应job显示在CI面板，environments视图上，而后能够反复操做相关job)

在下面这个最简单的表单里，environment关键字能够被设置为:

deploy_to_production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production

在上面这个例子中，deploy_to_production做业将会执行部署操做部署到production环境

environment:name

注意

• 在GitLab8.11中引入
• 8.11以前，你能够environment: environmentName这样设置环境名，但如今推荐你在name关键字下设置环境名
• name参数可使用任何已定义的CI变量，包括预约义变量，秘密变量和yaml文件定义的变量，可是你不能使用script脚本中定义的变量。

environmen名能够包括如下内容

• letters字母
• digits数字
• spaces空格
• -
• _
• /
• $
• {
• }

通用的环境名是qa，staging和production，不过你也能够设置任何你喜欢的名字

除了直接在environment后面定义环境名，你也可使用name关键字来定义环境名，将其当作一个分离的值来设置

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  #environment: production
  environment:
    name: production

environment:url

注意:

• 自GitLab8.11引入
• 在8.11以前，这个url只能在GitLabUi上设置，如今推荐你在yaml文件中书写
• url参数一样能使用任何CI的变量，除了script之中定义的之外

这是个可选选项，设置该选项，在gitLab ui上将会展现一个去往该url的连接按钮。

在下面的例子里，若是job作完了，gitlab将会在merge request页面或者environments或者deployments页面建立一个按钮，按钮指向https://prod.example.com

deploy to production:
  stage: deploy
  script: git push production HEAD:master
  environment:
    name: production
    url: https://prod.example.com

environment:on_stop

注意:

• 在GitLab8.13中引入
• 从8.14开始，当你在environment中设置了中断操做，gitlab将会在相关的分支被删除的时候自动触发中断对应行为

关闭environments能够经过在environment中定义关键字on_stop来实现。他指向了一个具名的job，该job的environment:action设置为stop

请参阅environment:action章节查看更多

environment:action

GitLab8.13引入

action关键字和on_stop关键字相关，定义在job的environment中，用于响应关闭环境的操做

下面是一个实例：

review_app:
  stage: deploy
  script: make deploy-app
  environment:
    name: review
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  script: make delete-app
  when: manual
  environment:
    name: review
    action: stop

在上面的例子中，咱们创建了一个review_app并部署到review环境，而且咱们在on_stop下一样定义了一个新的job名为stop_review_app。一旦review_app做业成功完成，ci将能够在手动操做的时候触发stop_review_app的任务，在这个例子中，咱们使用when来达到手动触发中止review app的功能。

stop_review_app做业须要结合如下关键字去定义：

1. when
2. environment:name
3. environment:action
4. stage (必须和写on_stop那个job定义的相同)

dynamic environments

动态环境

注意:

• 该特性自GitLab8.12和GITlAB Runner1.6被引入
• $CI_ENVIRONMENT_SLUG变量自 GitLab8.15引入
• name url参数能够是任何定义的CI变量，除了script里定义的之外

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

deploy as review app job会被标明为部署(deployment页面可见，10版里没有貌似)而且动态建立一个review/&dollar;CI_COMMIT_REF_NAME环境, &dollar;CI_COMMIT_REF_NAME是由Runner设置的环境变量(分支名). &dollar;CI_ENVIRONMENT_SLUG变量是基于enviroment:name的, 可是会作url安全处理. 在该例子中, 若是deploy as review app在分支pow下被执行, 凑出来的访问连接是这样的https://review-pow.example.com/.

你能够经过该访问连接来访问你的程序，这觉得这个app的服务主机已经配置好了(???)

想了解更多能够查看review-apps-nginx该示例

artifacts

注意：

• 自从gitlab Runner 0.7.0引入，而且windows平台不适用
• windows平台的支持是从版本1.0.0开始的
• 在Gitlab9.2以前，缓存将会在artifacts操做以后被从新储存
• 在此以后,缓存将会在artifacts操做以前被从新储存
• 目前来讲，不是全部解析器（shell, docker什么的那些）都支持artifacts，因此乖乖用cache
• 除非job做业成功完成，要否则artifacts默认不会被收集的

artifacts 被用于在job做业成功后将制定列表里的文件或文件夹附加到job上，传递给下一个job，若是要在两个job之间传递artifacts，你必须设置dependencies,下面有几个例子

传递全部binaries和.config：

artifacts:
  paths:
  - binaries/
  - .config

传递全部git没有追踪的文件

artifacts:
  untracked: true

传递binaries文件夹里全部内容和git没有追踪的文件

artifacts:
  untracked: true
  paths:
  - binaries/

禁止传递来的artifact:

job:
  stage: build
  script: make build
  dependencies: []

有时候用户可能只须要为打过标签的发行版建立artifacts去避免将临时构建的artifacts传递到生产服务器存储。

那么这时候咱们能够只为打tags的行为建立artifacts：

default-job:
  script:
    - mvn test -U
  except:
    - tags

release-job:
  script:
    - mvn package -U
  artifacts:
    paths:
    - target/*.war
  only:
    - tags

最终artifacts将会在job执行完毕后送到GitLab ui前台来，你能够直接下载它(在tag页，在details页，在pipeline页的下载按钮上都会出现)。

artifacts:name

GitLab8.6 GitLab Runner1.1.0引入

name指令容许你对artifacts压缩包重命名，你能够为每一个artifect压缩包都指定一个特别的名字，这样对你在gitlab上下载artifect的压缩包有用
.artifacts:name的值可使用任何预约义的变量，它的默认值是artifacts，因此若是你不设置，在gitlab上就会看到artifacts.zip的下载名

示例

建立一个压缩包命名为当前job名

job:
  artifacts:
    name: "$CI_JOB_NAME"

建立一个压缩包，命名为分支或者标签名，而且只包含未追踪的文件

job:
   artifacts:
     name: "$CI_COMMIT_REF_NAME"
     untracked: true

建立一个压缩包，命名为“job名_分支名”

job:
  artifacts:
    name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
    untracked: true

建立一个压缩包，命名为“场景阶段名_分支名”

job:
  artifacts:
    name: "${CI_JOB_STAGE}_${CI_COMMIT_REF_NAME}"
    untracked: true

若是你用的是 Windows batch脚本，请用%替换$号

若是你用的是powershell跑脚本，你须要使用&dollar;env:替换$

artifacts:when

GitLab 8.9 and GitLab Runner v1.3.0引入

artifacts:when用于job失败或者未失败时使用

artifacts:when能设置如下值：

1. on_success 这个值是默认的，当job成功时上传artifacts
2. on_failure 当job执行失败时，上床artifacts
3. always 无论失败与否，都上传

示例配置

当失败时上传artifacts

job:
  artifacts:
    when: on_failure

artifacts:expire_in

GitLab 8.9 and GitLab Runner v1.3.0中引入

artifacts:expire_in 用于设置artifacts上传包的失效时间. 若是不设置，artifacts的打包是永远存在于gitlab上的. expire_in 容许你指定artifacts过时时间, 在该期间内，artifacts包将储存在gitLab上.

若是设置了过时时间，你能够在job页面找到一个keep按钮，按了之后能够覆盖过时时间，让artifacts永远存在.

过时以后，用户将没法访问到artifacts包，artifacts将会在每小时执行的定时任务里被清除。

expire_in 的值要表示通过的时间. 下面是一些例子:

• '3 mins 4 sec'
• '2 hrs 20 min'
• '2h20min'
• '6 mos 1 day'
• '47 yrs 6 mos and 4d'
• '3 weeks and 2 days'

示例配置

设置artifacts一星期过时

job:
  artifacts:
    expire_in: 1 week

dependencies

GitLab 8.6 and GitLab Runner v1.1.1中引入

该特性须要和artifacts何用，是用于将artifacts在两个jobs之间（主要是两个不一样stage的job之间）传递的(下面几段翻译的巨烂，由于本身没有使用过，不知道究竟是啥意思)

注意全部以前的场景状态都是默认传递artifacts的

为了使用该特性，你须要在job上下文中定义dependencies而且列出全部运行本做业以前的做业（包涵artifacts下载设置的 ）。你只能在须要传递的job的前一个job（上一个stage状态）里定义。若是你在定义了artifacts的job里或者该job后面的job里定义依赖，runner会扔出一个错误。若是你想阻止下载artifacts，你须要设置一个空数组来跳过下载，当使用dependencies的时候，前一个job不会由于job执行失败或者手动操做的阻塞而报错

在下面的例子里，咱们定义了两个job有artifacts,其中一个是build:osx另外一个是build:linux，当test:osx的做业被执行的时候，从build:osx来的artifacts会被下载并解压缩出来，一样的事情发生在test:linux和build:linux的artifacts上

deploy job会下载全部的artifacts从全部以前的jobs下，这是因为他所处的stage优先级

build:osx:
  stage: build
  script: make build:osx
  artifacts:
    paths:
    - binaries/

build:linux:
  stage: build
  script: make build:linux
  artifacts:
    paths:
    - binaries/

test:osx:
  stage: test
  script: make test:osx
  dependencies:
  - build:osx

test:linux:
  stage: test
  script: make test:linux
  dependencies:
  - build:linux

deploy:
  stage: deploy
  script: make deploy

在上面一个例子中因为没有使用stages设置pipline场景顺序，因此执行顺序是build - test - deploy按照你的书写顺序来，artifacts被上传到gitlab服务器，在下一个dependencies

before_script and after_script

会复写全局设置

before_script:
- global before script

job:
  # 会执行该句而不执行全局设置
  before_script:
  - execute this instead of global before script
  script:
  - my command
  after_script:
  - execute this after my script

coverage

GitLab 8.17引入

coverage 容许你设置代码覆盖率输出，其值从job的输出获取

其值只能设置正则，因此必须用//包裹来表示正则语句,你必须转移特殊字符.

A simple example:

job1:
  script: rspec
  coverage: '/Code coverage: \d+\.\d+/'

retry

GitLab 9.5引入

retry容许用户设置重试次数。

当job失败，而且配置了，retry，则会在重试次数内进行重试

test:
  script: rspec
  retry: 2

Git Strategy（git策略）

GitLab 8.9 做为实验特性引入，任什么时候候均可能彻底移除该特性，慎用。
GIT_STRATEGY=none须要GitLab Runner 1.7以上版本支持

你能够经过在全局变量设置位置或者job局部变量设置位置来设置GIT_STRATEGY用以获取应用最近更新的代码。若是没有指定，默认的项目设置将会被使用。

该选项有三个可能的值：clone,fetch和none

clone是最慢的选项，若是设置该值，每一个job将会都克隆一遍仓库，确保项目工做空间老是原始的正确的。

variables:
  GIT_STRATEGY: clone

fetch是更快的操做选项，由于他重用了项目的工做空间（若是没有的话，会去clone）, git clean用于撤销上一个job的任何操做，git fetch是用来从新获取上一个job运行到当前job产生的commit

variables:
  GIT_STRATEGY: fetch

none也一样重用了项目空间（可是他会跳过全部git操做，包括若是存在的gitlab runner的预克隆脚本）。其主要用于只是为了操做artifacts的job上（例如depoly部署行为）。此时Git仓库的数据多是存在的，但它必定不是最新的。因此在设置了none的job里你应该依赖从cache或者artifacts来的数据，而不是仓库数据。

variables:
  GIT_STRATEGY: none

Git Checkout

GitLab Runner 9.3引入

GIT_CHECKOUT变量是和GIT_STRATEGY:clone, GIT_STRATEGY:fetch合用的，用来指定git checkout命令是否须要被执行，若是没有设置GIT_CHECKOUT，那么runner任务将会使用默认值true，也就是每次checkout相应分支。GIT_CHECKOUT能够设置在全局variables上，也能够设置在job的variables上

可是若是这个值被设置为false,runner将会有如下行为：

• 当作fetch操做的时候，更新仓库并保留当前版本的工做副本
• 当作clone操做的时候，克隆仓库并保留默认分支的工做副本

若是设置这个值为true，这意味着，runner的clone和fetch策略都会让项目工做区的工做副本更新到最新版本

variables:
  GIT_STRATEGY: clone
  GIT_CHECKOUT: false
script:
  - git checkout master
  - git merge $CI_BUILD_REF_NAME

Git Submodule Strategy

Requires GitLab Runner v1.10+

GIT_SUBMODULE_STRATEGY用于在构建以前控制git子模块用，像GIT_STRATEGY同样，他能够在全局variables里设置，也能在jobs下的variables设置

有三个可选值 none,normal,recursive

• none默认不引入子模块，和，Runner1.10之前的默认行为同样，也是默认值

• normal默认只引入第一级子模块,跟下面相等

  git submodule sync
  git submodule update --init

• recursive意味着递归下载全部子模块，和下面的操做相等

  git submodule sync --recursive
  git submodule update --init --recursive

git策略和git子模块策略只是一种配置糖，你彻底能够执行本身的脚本完成相同的操做（git策略的其余选项能够加快做业执行速度什么的，那要看我的需求了。）因此若是你要配置子模块策略，你要保证你项目底下有.gitmodules文件，并配置了如下内容:

• 公开的仓库http(s) url地址或者
• 在同一个GitLab服务器上的相对仓库地址，查看git submodules文档

Shallow cloning (浅克隆)

该特性是gitLab8.9引入的实验特性，在将来任什么时候候都有可能被移除

你能够经过GIT_DEPTH来设置抓取或者克隆深度。这将使得仓库进行浅克隆， 若是你的仓库有特别大量的commits或者仓库很久没更新了，该设置将显著的提升克隆速度。该参数会发送给git fetch和git clone操做(其实就至关于git fetch --depth=xxx, git clone --depth=xxx。可是因为git fetch和git clone是runner在执行job时帮你作的，因此须要此配置。)

注意，若是你的克隆深度设置为1，而且此时你在执行一个队列的job或者重试一个job，你的job做业可能会失败的

因为git抓取和克隆操做是基于一个ref的（例如ref为一个分支名），因此Runners不能直接去克隆一个具体的commit(用sha哈希索引的)。若是在执行队列里有多个job，或者你正在重试执行某个job，那么此时要求你须要job测试的commit必须在克隆的仓库的git历史里可查，要否则会报错的。若是设置的GIT_DEPTH值过小，你可能克隆不到更早一些的commits。此时，你在job日志里会看到一条unresolved reference的日志。这个时候你可能考虑一下，把GIT_DEPTH值设置高一些.

当设置了GIT_DEPTH的时候，因为仓库只呈现一部分git历史，因此一些依赖于git describe的job(那些only: tags的那种)可能没法正常工做

抓取或者克隆最新三条commits:

variables:
  GIT_DEPTH: "3"

Hidden keys(jobs)(job隐藏键名)

自 GitLab 8.6 and GitLab Runner v1.1.1引入

若是你想暂时屏蔽某job做业，而不是直接注释该job定义:

#hidden_job:
#  script:
#    - run test

那么你大可没必要所有用#注释掉，你能够在job key名钱加一个点，此时gitlab ci执行到这就不会执行该job了：

.hidden_job:
  script:
    - run test

你可使用该特性来忽略job，也可使用YAML的专有特性（语法）来替换隐藏件

Special YAML features (YAML专有特性)

你可使用YAML的专有语法和特性来定义你的.gitlab-ci.yml,例如（锚点&，别名*，合并数据<<）。经过YAML语法特性能够减轻你的配置的复杂性

阅读更多

Anchors(锚点)

GitLab 8.6 and GitLab Runner v1.1.1引入

YAML有一个名叫‘锚点’的遍历特性，该特性可让你在文档中方便的复制内容，锚点能够用来复制属性或者继承属性，这里有一个很好的例子，利用锚点和隐藏键来为你的job制做job模板

下面的例子使用了锚点的map数据合并，该例子将建立两个job，test1和test2，他们都会继承.job_template的参数，同时他们拥有本身的script定义:

.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test1 project

test2:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test2 project

&锚点符号后跟的是设置的锚点名（job_definition）,<<符号意思是“合并给与的hash map到当前map里来”，*表示索引被命名的锚点(job_definition)，通过解析后，上面的例子将是这样的:

.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test1 project

test2:
  image: ruby:2.1
  services:
    - postgres
    - redis
  script:
    - test2 project

让咱们来看看其余例子，此次咱们使用锚点来定义两个服务设置的模板，该例子将建立两个job，test:postgres和test:mysql，他们将共享由.job_template定义的script指令，并分别适配由.postgre_services和.mysql_services磨边定义的services指令。

.job_template: &job_definition
  script:
    - test project

.postgres_services:
  services: &postgres_definition
    - postgres
    - ruby

.mysql_services:
  services: &mysql_definition
    - mysql
    - ruby

test:postgres:
  <<: *job_definition
  services: *postgres_definition

test:mysql:
  <<: *job_definition
  services: *mysql_definition

上面的例子展开等同于:

.job_template:
  script:
    - test project

.postgres_services:
  services:
    - postgres
    - ruby

.mysql_services:
  services:
    - mysql
    - ruby

test:postgres:
  script:
    - test project
  services:
    - postgres
    - ruby

test:mysql:
  script:
    - test project
  services:
    - mysql
    - ruby

Triggers（触发器）

Triggers被用于重建特定分支，tag或者commit，他是api触发的。

阅读更多关于Triggers的内容

pages

pages是一类特殊的job，他是设计被用来将你的静态内容（你的web服务须要用到的）上传到GitLab上（相似对应pages分支展现静态页面对吧）。它有指定的特殊语法，下面连个设置是必须的

1. 任何静态内容都必须放在一个叫public/的文件夹下
2. 你必须定义artifacts的上传路径为public/

下面的例子简单的将静态资源移动到public文件夹下，为了防止无限执行cp，咱们建立一个文件夹为.public，最后将.public更名为public

pages:
  stage: deploy
  script:
  - mkdir .public
  - cp -r * .public
  - mv .public public
  artifacts:
    paths:
    - public
  only:
  - master

阅读更多GitLab Pages user documentation

验证.gitlab-ci.yml的合法性

gitlab都有一个Lint工具，你能够在gitlab实例的/ci/lint下找到连接（ci页面就有）

使用保留关键字

若是你发现你使用某些特定值(例如true或者false)可是发现验证合法性不经过，请尝试使用引号包住他们，或者在你runner下把他们移动到其余地方（例如/bin/true）

跳过job

若是你的commit信息包涵[ci skip]或者[skip ci]，不论大消息，这个commit将会被建立，可是job会被跳过

官方例子

Visit the examples README to see a list of examples using GitLab CI with various languages.

gitlab-ci配置详解(一)
gitlab-ci配置详解(二)

资料

centos7简单安装gitlab-ce/ee(官网quick start)
GitLab简明安装指南
GitLab设置stmp发件
postfix mail command not find
gitLab修改默认端口
GitLab使用已有的nginx服务
GitLab-CI与GitLab-Runner
GitLab-Runner官方文档
基于Gitlab CI搭建持续集成环境
如何汉化GitLab
非GitLab集成包手装GitLab