.gitlab-ci.yml
.gitlab-ci.yml 用來配置 CI 用你的項目中做哪些操作，這個文件位於倉庫的根目錄。
當有新內容 push 到倉庫，或者有代碼合併後， GitLab 會查找是否有 .gitlab-ci.yml 文件，如果文件存在， Runners 將會根據該文件的內容開始 build 本次 commit 。
.gitlab-ci.yml 使用 YAML 語法， 你需要格外注意縮進格式，要用空格來縮進，不能用 tabs 來縮進。
Stages
Stages 表示構建階段，說白了就是上面提到的流程。默認有3個 stages ： build , test , deploy 。我們可以在一次 Pipeline 中定義多個 Stages ，這些 Stages 會有以下特點：
所有 Stages 會按照順序運行，即當一個 Stage 完成後，下一個 Stage 纔會開始
只有當所有 Stages 完成後，該構建任務 (Pipeline) 纔會成功
如果任何一個 Stage 失敗，那麼後面的 Stages 不會執行，該構建任務 (Pipeline) 失敗
Jobs
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/
跳過job
如果你的 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中添加）
Docker Executor
所有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。