此篇部落格大多以官方文檔翻譯得來：通過 .gitlab-ci.yml配置CI/CD任務
相信熟悉dockerfile和ansible的應該對這個熟悉很快！
此文檔用于描述.gitlab-ci.yml文法，.gitlab-ci.yml檔案被用來管理項目的runner 任務。
.gitlab-ci.yml 從7.12版本開始，GitLab CI使用YAML檔案(.gitlab-ci.yml)來管理項目配置。該檔案存放于項目倉庫的根目錄，它定義該項目如何建構。
開始建構之前YAML檔案定義了一系列帶有限制說明的任務。這些任務都是以任務名開始并且至少要包含script部分：
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
上面這個例子就是一個最簡單且帶有兩個獨立任務的CI配置，每個任務分别執行不同的指令。
script可以直接執行系統指令(例如：./configure;make;make install)或者是直接執行腳本(test.sh)。
任務是由Runners接管并且由伺服器中runner執行。更重要的是，每一個任務的執行過程都是獨立運作的。
用下面這個例子來說明YAML文法還有更多複雜的任務：
image: ruby:2.1
services:
- postgres
before_script:
- bundle install
after_script:
- rm secrets
stages:
- build
- test
- deploy
job1:
stage: build
script:
- execute-script-for-job1
only:
- master
tags:
- docker
下面列出保留字段，這些保留字段不能被定義為job名稱：
image和services
這兩個關鍵字允許使用一個自定義的Docker鏡像和一系列的服務，并且可以用于整個job周期。詳細配置文檔請檢視a separate document。
before_script
before_script用來定義所有job之前運作的指令，包括deploy(部署) jobs，但是在修複artifacts之後。它可以是一個數組或者是多行字元串。
after_script
GitLab 8.7 開始引入，并且要求Gitlab Runner v1.2
after_script用來定義所有job之後運作的指令。它必須是一個數組或者是多行字元串
stages
stages用來定義可以被job調用的stages。stages的規範允許有靈活的多級pipelines。
stages中的元素順序決定了對應job的執行順序：
1. 相同stage的job可以平行執行。
2. 下一個stage的job會在前一個stage的job成功後開始執行。
接下仔細看看這個例子，它包含了3個stage：
stages:
- build
- test
- deploy
首先，所有build的jobs都是并行執行的。
所有build的jobs執行成功後，test的jobs才會開始并行執行。
所有test的jobs執行成功，deploy的jobs才會開始并行執行。
所有的deploy的jobs執行成功，commit才會标記為success
任何一個前置的jobs失敗了，commit會标記為failed并且下一個stages的jobs都不會執行。
這有兩個特殊的例子值得一提：
如果.gitlab-ci.yml中沒有定義stages，那麼job's stages 會預設定義為 build，test 和 deploy。
如果一個job沒有指定stage，那麼這個任務會配置設定到test stage。
types
已廢除，将會在10.0中移除。用stages替代。
與stages同義
variables
GitLab Runner V0.5.0. 開始引入
GItLab CI 允許在.gitlab-ci.yml檔案中添加變量，并在job環境中起作用。因為這些配置是存儲在git倉庫中，是以最好是存儲項目的非敏感配置，例如：
variables:
DATABASE_URL:"postgres://[email protected]/my_database"
這些變量可以被後續的指令和腳本使用。服務容器也可以使用YAML中定義的變量，是以我們可以很好的調控服務容器。變量也可以定義成job level。
除了使用者自定義的變量外，Runner也可以定義它自己的變量。CI_COMMIT_REG_NAME就是一個很好的例子，它的值表示用于建構項目的分支或tag名稱。除了在.gitlab-ci.yml中設定變量外，還有可以通過GitLab的界面上設定私有變量。
更多關于variables。
cache
Gitlab Runner v0.7.0 開始引入。
cache用來指定需要在job之間緩存的檔案或目錄。隻能使用該項目工作空間内的路徑。
從GitLab 9.0開始，pipelines和job就預設開啟了緩存
如果cache定義在jobs的作用域之外，那麼它就是全局緩存，所有jobs都可以使用該緩存。
緩存binaries和.config中的所有檔案：
rspec:
script: test
cache:
paths:
- binaries/
- .config
緩存git中沒有被跟蹤的檔案：
rspec:
script: test
cache:
untracked: true
緩存binaries下沒有被git跟蹤的檔案：
rspec:
script: test
cache:
untracked: true
paths:
- binaries/
job中優先級高于全局的。下面這個rspecjob中将隻會緩存binaries/下的檔案：
cache:
paths:
- my/files
rspec:
script: test
cache:
key: rspec
paths:
- binaries/
注意，緩存是在jobs之前進行共享的。如果你不同的jobs緩存不同的檔案路徑，必須設定不同的cache:key，否則緩存内容将被重寫。
緩存隻是盡力而為之，是以别期望緩存會一直存在。檢視更多詳細内容，請查閱GitLab Runner。
緩存key
GitLab Runner v1.0.0 開始引入。
key指令允許我們定義緩存的作用域(親和性)，可以是所有jobs的單個緩存，也可以是每個job，也可以是每個分支或者是任何你認為合适的地方。
它也可以讓你很好的調整緩存，允許你設定不同jobs的緩存，甚至是不同分支的緩存。
cache:key可以使用任何的預定義變量。
預設key是預設設定的這個項目緩存，是以預設情況下，每個pipelines和jobs中可以共享一切，從GitLab 9.0開始。
配置示例
緩存每個job：
cache:
key: "$CI_JOB_NAME"
untracked: true
緩存每個分支：
cache:
key: "$CI_COMMIT_REF_NAME"
untracked: true
緩存每個job且每個分支：
cache:
key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME"
untracked: true
緩存每個分支且每個stage：
cache:
key: "$CI_JOB_STAGE/$CI_COMMIT_REF_NAME"
untracked: true
如果使用的Windows Batch(windows批處理)來跑腳本需要用%替代$：
cache:
key: "%CI_JOB_STAGE%/%CI_COMMIT_REF_NAME%"
untracked: true
Jobs
.gitlab-ci.yml允許指定無限量jobs。每個jobs必須有一個唯一的名字，而且不能是上面提到的關鍵字。job由一列參數來定義jobs的行為。
job_name:
script:
- rake spec
- coverage
stage: test
only:
- master
except:
- develop
tags:
- ruby
- postgres
allow_failure: true
script
script是Runner執行的yaml腳本。舉個例子：
job:
script: "bundle exec rspec"
該參數也可以用數組包含多個指令：
job:
script:
- uname -a
- bundle exec rspec
有時候，script指令需要被單引号或者是雙引号包裹起來。舉個例子，當指令中包含冒号(:)時，script需要被包在雙引号中，這樣YAML解析器才可以正确解析為一個字元串而不是一個鍵值對(key:value)。使用這些特殊字元的時候一定要注意：:,{,},[,],,,&,*,#,?,|,-,<,>,=,!。
stage
stage允許一組jobs進入不同的stages。jobs在相同的stage時會parallel同時進行。查閱stages更多的用法請檢視stages。
only and except
only和except是兩個參數用分支政策來限制jobs建構：
only定義哪些分支和标簽的git項目将會被job執行。
except定義哪些分支和标簽的git項目将不會被job執行。
下面是refs政策的使用規則：
only和except可同時使用。如果only和except在一個job配置中同時存在，則以only為準，跳過except(從下面示例中得出)。
only和except可以使用正規表達式。
only和except允許使用特殊的關鍵字：branches，tags和triggers。
only和except允許使用指定倉庫位址但不是forks的倉庫(檢視示例3)。
在下面這個例子中，job将隻會運作以issue-開始的refs(分支)，然而except中設定将被跳過。
job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches
在下面這個例子中，job将隻會執行有tags的refs，或者通過API觸發器明确地請求建構。
job:
# use special keywords
only:
- tags
- triggers
倉庫路徑隻能用于父級倉庫執行jobs，而不是forks：
job:
only:
- [email protected]/gitlab-ce
except:
- [email protected]/gitlab-ce
上面這個例子将會為所有的分支執行job，但master分支除外。
Job variables
在job中是可以使用關鍵字variables來定義job變量。它的運作原理跟global-level是一樣的，但是它允許設定特殊的job變量。
當設定了job級别的關鍵字variables，它會覆寫全局YAML和預定義中的job變量。想要關閉全局變量可以在job中設定一個空數組：
job_name:
variables: []
Job變量的優先級關系可檢視variables文檔說明。
tags
tags可以從允許運作此項目的所有Runners中選擇特定的Runners來執行jobs。
在注冊Runner的過程中，我們可以設定Runner的标簽，比如ruby，postgres，development。
tags可通過tags來指定特殊的Runners來運作jobs：
job:
tags:
- ruby
- postgres
上面這個示例中，需要確定建構此job的Runner必須定義了ruby和postgres這兩個tags。
allow_failure
allow_failure可以用于當你想設定一個job失敗的之後并不影響後續的CI元件的時候。失敗的jobs不會影響到commit狀态。
當開啟了允許job失敗，所有的intents和purposes裡的pipeline都是成功/綠色，但是也會有一個"CI build passed with warnings"資訊顯示在merge request或commit或job page。這被允許失敗的作業使用，但是如果失敗表示其他地方應采取其他（手動）步驟。
下面的這個例子中，job1和job2将會并列進行，如果job1失敗了，它也不會影響進行中的下一個stage，因為這裡有設定了allow_failure: true。
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
when
when is used to implement jobs that are run in case of failure or despite the failure.
when可以設定以下值：
on_success - 隻有前面stages的所有工作成功時才執行。 這是預設值。
on_failure - 目前面stages中任意一個jobs失敗後執行。
always - 無論前面stages中jobs狀态如何都執行。
`manual ` - 手動執行(GitLab8.10增加)。更多請檢視手動操作。
舉個例子：
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
腳本說明：
隻有當build_job失敗的時候才會執行`cleanup_build_job 。
不管前一個job執行失敗還是成功都會執行`cleanup_job 。
可以從GitLab界面中手動執行deploy_jobs。
Manual actions
GitLab 8.10 開始引入手動執行。GitLab 9.0 開始引入手動停止。GitLab 9.2 開始引入保護手動操作。
手動操作指令是不自動執行的特殊類型的job；它們必須要人為啟動。手動操作指令可以從pipeline，build，environment和deployment視圖中啟動。
部署到生産環境是手動操作指令的一個很好示例。
了解更多請檢視environments documentation。
手動操作指令可以是可選的或阻塞。在定義了手動執行的那個stage中，手動操作指令将會停止pipline中的自動執行指令。當有人通過點選play按鈕來執行需要手動執行的job時，可以來恢複pipeline的執行。
當pipeline被阻塞時，即使是pipeline是成功狀态也不會merge。被阻塞的pipelines也有一個特殊的狀态，叫manual。
手動操作指令預設是不阻塞的。如果你想要手動操作指令産生阻塞，首先需要在job的配置檔案.gitlab-ci.yml中添加allow_failure:false。
可選的手動操作指令預設設定allow_failure:true。
可選動作的狀态不影響整個pipeline的狀态。
手動操作指令被認為是寫操作，是以目前使用者觸發操作時，必須擁有操作保護分支的權限。換句話說，為了觸發一個手動操作指令到pipeline中正在運作的指定分支，目前使用者必須擁有推送到這分支的權限。
enviroment
注意：
GitLab 8.9 開始引入。
更多關于environment說明或者示例可以檢視 documentation about environments。
environment用于定義job部署到特殊的環境中。如果指定了environment，并且沒有該名稱下的環境，則會自動建立新環境。
在最簡單的格式中，環境關鍵字可以定義為：
deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: production
在上面這個例子中，deploy to profuctionjob将會執行部署到production環境的操作。
environment:name
注意
GitLab 8.11 開始引入。
在GitLab8.11之前，環境名稱定義為environment:production。現在推薦的做法是定義為name關鍵字。
environment名稱可以包含：
英文字母(letters)
數字(digits)
空格(spaces)
-
_
/
$
{
}
常用的名稱有qa,staging，和production，當然你可以在你的工作流中使用任意名字。
除了在environment關鍵字右邊緊跟name定義方法外，也是可以為環境名稱單獨設定一個值。例如，用name關鍵字在environment下面設定：
deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: production
environment:url
注意：
GitLab 8.11 開始引用。
在GitLab 8.11之前，URL隻能在GitLab's UI中添加。現在推薦的定義方法是在.gitlab-ci.yml。
這是設定一個可選值，它會顯示在按鈕中，點選它可以帶你到設定的URL頁面。
在下面這個例子中，如果job都成功完成了，在environment/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
注意：
GitLab 8.13中開始引入。
從GitLab 8.14開始，當在environment中定義了一個stop操作，GitLab将會在相關聯的分支本删除時自動觸發一個stop操作。
關閉(停止)environments可以通過在environment下定義關鍵字on_stop來實作。它定義了一個不同的job，用于關閉environment。
請檢視environment:action子產品中例子。
environment:action
Gitlab 8.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_appjob來部署到review環境中，同時我們也定義了一個新stop_review_appjob在on_stop中。一旦review_appjob執行完成并且成功，它将觸發定義在when中的stop_review_appjob。在這種情況下，我們設定為manual，需要通過GitLab's web界面來允許manual action。
stop_review_appjob需要定義下面這些關鍵字：
when - 說明
environment:name
environment:action
stage需要和review_app相同，以便分支删除被删除的時候自動執行停止。
dynamic environment
注意：
GitLab 8.12開始引入，并且要求GitLab Runner 1.6 。
GitLab 8.15開始引入$CI_ENVIRONMENT_SLUG。
environment也可以是代表配置項，其中包含name和url。這些參數可以使用任何的CI variables(包括預定義、安全變量和.gitlab-ci.yml中的變量)。
舉個例子：
deploy as review app:
stage: deploy
script: make deploy
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com/
當$CI_COMMIT_REF_NAME 被Runner設定為environment variable時，deply as review appjob将會被指定部署到動态建立revuew/$CI_COMMIT_REF_NAME的環境中。$CI_ENVIRONMENT_SLUG變量是基于環境名稱的，最終組合成完整的URLs。在這種情況下，如果deploy as review appjob是運作在名稱為pow的分支下，那麼可以通過URLhttps"//review-pw.example.com/來通路這個環境。
這當然意味着托管應用程式的底層伺服器已經正确配置。
常見的做法是為分支建立動态環境，并講它們作為Review Apps。可以通過https://gitlab.com/gitlab-exa...上檢視使用Review Apps的簡單示例。
artifacts
注意：
非Windows平台從GitLab Runner v0.7.0中引入。
Windows平台從GitLab Runner V1.0.0中引入。
在GItLab 9.2之前，在artifacts之後存儲緩存。
在GItLab 9.2之後，在artifacts之前存儲緩存。
目前并不是所有的executors都支援。
預設情況下，job artifacts 隻正對成功的jobs收集。
artifacts用于指定成功後應附加到job的檔案和目錄的清單。隻能使用項目工作間内的檔案或目錄路徑。如果想要在不通的job之間傳遞artifacts，請查閱依賴關系。以下是一些例子：
發送binaries和.config中的所有檔案：
artifacts:
paths:
- binaries/
- .config
發送所有沒有被Git跟蹤的檔案：
artifacts:
untracked: true
發送沒有被Git跟蹤和binaries中的所有檔案：
artifacts:
untracked: true
paths:
- binaries/
定義一個空的dependencies可以禁用artifact傳遞：
job:
stage: build
script: make build
dependencies: []
有時候隻需要為标簽為releases建立artifacts，以避免将臨時建構的artifacts傳遞到生産伺服器中。
隻為tags建立artifacts（default-job将不會建立artifacts）：
default-job:
script:
- mvn test -U
except:
- tags
release-job:
script:
- mvn package -U
artifacts:
paths:
- target/*.war
only:
- tags
在job成功完成後artifacts将會發送到GitLab中，同時也會在GitLab UI中提供下載下傳。
artifacts:name
GitLab 8.6 和 Runner v1.1.0 引入。
name允許定義建立的artifacts存檔的名稱。這樣一來，我們可以為每個存檔提供一個唯一的名稱，當需要從GitLab中下載下傳是才不會混亂。artifacts:name可以使用任何的預定義變量(predefined variables)。它的預設名稱為artifacts，當下載下傳是就變成了artifacts.zip。
配置示例
通過使用目前job的名字作為存檔名稱：
job:
artifacts:
name: "$CI_JOB_NAME"
使用目前分支名稱或者是tag作為存到名稱，隻存檔沒有被Git跟蹤的檔案：
job:
artifacts:
name: "$CI_COMMIT_REF_NAME"
untracked: true
使用目前job名稱和目前分支名稱或者是tag作為存檔名稱，隻存檔沒有被Git跟蹤的檔案：
job:
artifacts:
name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
untracked: true
使用目前stage和分支名稱作為存檔名稱：
job:
artifacts:
name: "${CI_JOB_STAGE}_${CI_COMMIT_REF_NAME}"
untracked: true
如果是使用Windows批處理來運作yaml腳本，需要用%替換$：
job:
artifacts:
name: "%CI_JOB_STAGE%_%CI_COMMIT_REF_NAME%"
untracked: true
artifacts:when
GitLab 8.9和GitLab Runner v1.3.0 引入。
在job失敗的時候，artifacts:when用來上傳artifacts或者忽略失敗。
artifacts:when可以設定一下值：
on_success - 當job成功的時候上傳artifacts。預設值。
on_failure - 當job失敗的時候上傳artifacts。
always - 不論job失敗還是成功都上傳artifacts。
示例配置
隻在job失敗的時候上傳artifacts。
job:
artifacts:
when: on_failure
artifacts:expire_in
GitLab 8.9 和 GitLab Runner v1.3.0 引入。
artifacts:expire_in用于過期後删除郵件上傳的artifacts。預設情況下，artifacts都是在GitLab中永久儲存。expire_in允許設定設定artifacts的存儲時間，從它們被上傳存儲到GitLab開始計算。
可以通過job頁面的Keep來修改有效期。
過期後，artifacts會被通過一個預設每小時執行一次的定時job删除，是以在過期後無法通路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 和 GitLab RUnner v1.1.1引入。
這個功能應該與artifacts一起使用，并允許定義在不同jobs之間傳遞artifacts。
注意：所有之前的stages都是預設設定通過。
如果要使用此功能，應該在上下文的job中定義dependencies，并且列出之前都已經通過的jobs和可下載下傳的artifacts。你隻能在目前執行的stages前定義jobs。你如果在目前stages或者後續的stages中定義了jobs，它将會報錯。可以通過定義一個空數組是目前job跳過下載下傳artifacts。
在接下來的例子中，我們定義兩個帶artifacts的jobs，build:osx和build:linux。當test:osx開始執行的時候，build:osx的artifacts就會開始下載下傳并且會在build的stages下執行。同樣的會發生在test:linux，從build:linux中下載下傳artifacts。
因為stages的優先級關系，deployjob将會下載下傳之前jobs的所有artifacts：
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
before_script 和 after_script
它可能會覆寫全局定義的before_script和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中提取輸出。
在這裡正規表達式是唯一有效的值。是以，字元串的前後必須使用/包含來表明一個正确的正規表達式規則。特殊字元串需要轉義。
一個簡單的例子：
job1:
coverage: '/Code coverage: \d+\.\d+/'
Git Strategy
GitLab 8.9中以試驗性功能引入。将來的版本中可能改變或完全移除。GIT_STRATEGY要求GitLab Runner v1.7+。
你可以通過設定GIT_STRATEGY用于擷取最新的代碼，可以再全局variables或者是在單個job的variables子產品中設定。如果沒有設定，将從項目中使用預設值。
可以設定的值有：clone，fetch，和none。
clone是最慢的選項。它會從頭開始克隆整個倉庫，包含每一個job，以確定項目工作區是最原始的。
GIT_STRATEGY: clone
當它重新使用項目工作區是，fetch是更快（如果不存在則傳回克隆）。git clean用于撤銷上一個job做的任何改變，git fetch用于擷取上一個job到現在的的commit。
variables:
GIT_STRATEGY: fetch
none也是重新使用項目工作區，但是它會跳過所有的Git操作（包括GitLab Runner前的克隆腳本，如果存在的話）。它主要用在操作job的artifacts（例如：deploy）。Git資料倉庫肯定是存在的，但是他肯定不是最新的，是以你隻能依賴于從項目工作區的緩存或者是artifacts帶來的檔案。
variables:
GIT_STRATEGY: none
Git Checout
GitLab Runner 9.3 引入。
當GIT_STRATEGY設定為clone或fetch時，可以使用GIT_CHECKOUT變量來指定是否應該運作git checkout。如果沒有指定，它預設為true。就像GIT_STRATEGY一樣，它可以設定在全局variables或者是單個job的variables中設定。
如果設定為false，Runner就會：
fetch - 更新倉庫并在目前版本中保留工作副本，
clone - 克隆倉庫并在預設分支中保留工作副本。
Having this setting set to true will mean that for both clone and fetch strategies the Runner will checkout the working copy to a revision related to the CI pipeline:
【如果設定這個為true将意味着clone和fetch政策都會讓Runner執行項目工作區更新到最新：】
variables:
GIT_STRATEGY: clone
GIT_CHECKOUT: false
script:
- git checkout master
- git merge $CI_BUILD_REF_NAME
需要GitLab Runner v1.10+。
GIT_SUBMODULE_STRATEGY變量用于在建構之前拉取代碼時，Git子子產品是否或者如何被引入。就像GIT_STRATEGY一樣，它可在全局variables或者是單個job的variables子產品中設定。
它的可用值有：none，normal和recursive：
none意味着在拉取項目代碼時，子子產品将不會被引入。這個是預設值，與v1.10之前相同的。
normal意味着在隻有頂級子子產品會被引入。它相當于：
git submodule sync
git submodule update --init
recursive意味着所有的子子產品（包括子子產品的子子產品）都會被引入，他相當于：
git submodule sync --recursive
git submodule update --init --recursive
注意：如果想要此功能正常工作，子子產品必須配置（在.gitmodules）下面中任意一個：
可通路的公共倉庫http(s)位址，
在同一個GitLab伺服器上有一個可通路到另外的倉庫的真實位址。更多檢視Git 子子產品文檔。
Job stages attempts
GitLab引入，要求GItLab Runner v1.9+。
正在執行的job将會按照你設定嘗試次數依次執行下面的stages：
預設是一次嘗試。
例如：
variables:
GET_SOURCES_ATTEMPTS: 3
你可以在全局variables子產品中設定，也可以在單個job的variables子產品中設定。
Shallow cloning
GitLab 8.9 以實驗性功能引入。在将來的版本中有可能改變或者完全移除。
你可以通過GIT_DEPTH來指定抓取或克隆的深度。它可淺層的克隆倉庫，這可以顯著加速具有大量送出和舊的大型二進制檔案的倉庫的克隆。這個設定的值會傳遞給git fetch和git clone。
注意：如果設定depth=1，并且有一個jobs隊列或者是重試jobs，則jobs可能會失敗。
由于Git抓取和克隆是基于一個REF，例如分支的名稱，是以Runner不能指定克隆一個commit SHA。如果隊列中有多個jobs，或者您正在重試舊的job，則需要測試的送出應該在克隆的Git曆史記錄中存在。設定GIT_DEPTH太小的值可能會導緻無法運作哪些舊的commits。在job日志中可以檢視unresolved reference。你應該考慮設定GIT_DEPTH為一個更大的值。
當GIT_DEPTH隻設定了部分存在的記錄時，哪些依賴于git describe的jobs也許不能正确的工作。
隻抓取或克隆最後的3次commits：
variables:
GIT_DEPTH: "3"
Hidden keys
GitLab 8.6 和 GitLab Runner v1.1.1引入。
Key 是以.開始的，GitLab CI 将不會處理它。你可以使用這個功能來忽略jobs，或者用Special YAML features 轉換隐藏鍵為模版。
在下面這個例子中，.key_name将會被忽略：
.key_name:
script:
- rake spec
Hidden keys 可以是像普通CI jobs一樣的哈希值，但你也可以利用special YAMLfeatures來使用不同類型的結構。
Special YAML features
使用special YAML features 像anchors(&)，aliases(*)和map merging(<<)，這将使您可以大大降低.gitlab-ci.yml的複雜性。
檢視更多YAML features。
Anchors
GitLab 8.6 和 GitLab Runner v1.1.1引入。
YAML有個友善的功能稱為"錨",它可以讓你輕松的在文檔中複制内容。Anchors可用于複制/繼承屬性，并且是使用hidden keys來提供模版的完美示例。
下面這個例子使用了anchors和map merging。它将會建立兩個jobs，test1和test2，該jobs将內建.job_template的參數，每個job都自定義腳本：
.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
&在anchor的名稱(job_definition)前設定，<<表示"merge the given hash into the current one"，*包括命名的anchor(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
讓我們來看另外一個例子。這一次我們将用anchors來定義兩個服務。兩個服務會建立兩個job，test:postgres和test:mysql，他們會在.job_template中共享定義的script指令，以及分别在.postgres_services和.mysql_services中定義的service指令：
.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
你可以看到hidden keys被友善的用作模版。
Triggers
Triggers 可用于強制使用API調用重建特定分支，tag或commits。
在triggers文檔中檢視更多。
pages
pages是一個特殊的job，用于将靜态的内容上傳到GitLab，可用于為您的網站提供服務。它有特殊的文法，是以必須滿足以下兩個要求：
任何靜态内容必須放在public/目錄下
artifacts必須定義在public/目錄下
下面的這個例子是将所有檔案從項目根目錄移動到public/目錄。.public工作流是cp，并且它不會循環複制public/本身。
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
only:
- master
更多内容請檢視GitLab Pages使用者文檔。
Validate the .gitlab-ci.yml
GitLab CI的每個執行個體都有一個名為Lint的嵌入式調試工具。 你可以在gitlab執行個體的/ci/lint下找到該連結。
原文：https://blog.csdn.net/weixin_37934134/article/details/80736957