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