一.什麼是gitlab-ci.yml文件
GitLab提供持續集成服務。如果
將.gitlab-ci.yml文件添加到存儲庫的根目錄，並將GitLab項目配置爲使用Runner，則每次提交或推送都會觸發CI 管道。
該.gitlab-ci.yml文件是您配置CI如何處理項目的位置。它位於存儲庫的根目錄中。在對存儲庫進行任何推送時，GitLab都會查找該.gitlab-ci.yml 文件，並根據該文件的內容在Runners上啓動作業。
因爲.gitlab-ci.yml是在存儲庫中並且受版本控制的，所以舊版本仍然可以成功構建，fork可以輕鬆使用CI，分支可以具有不同的管道和作業，並且您擁有CI的唯一真實來源。您可以.gitlab-ci.yml
在我們的博客中閱讀有關使用它的原因的更多信息
工作是：
定義了約束，指出應在什麼條件下執行它們。
具有任意名稱的頂級元素，並且必須至少包含script子句。
不限制可以定義多少個。
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
作業名稱不可用
每個作業必須具有唯一的名稱，但是有一些保留keywords名稱不能用作作業名稱：
image
services
stages
types
before_script
after_script
variables
cache
include
二 配置參數詳解
stages
定義pipeline的全部階段（stage），階段內所有任務並行執行，全部執行成功開始下一階段任務，任何階段內任意job執行失敗都會導致pipeline失敗，所有stage，job執行成功後pipeline會顯示pass。如果未定義stages，則默認有build、test、deploy三個階段，如果未定義stage，則默認test階段
stages:
- build
- deploy
- test
variables
在作業級別上定義作業變量。
script
由runner執行的shell腳本
image
使用的docker 鏡像，這裏docker鏡像的地址，也可用：image:name和image:entrypoint。
services
使用docker服務映像。也可用：services:name，services:alias，services:entrypoint，和services:command。
before_script
執行作業之前執行的一段shell腳本
after_script
執行完作業執行一段的shell腳本
stage
定義一個作業階段（默認值：）test。
only/except
用於設置作業策略以限制創建作業的時間
rules
件列表，用於評估和確定作業的選定屬性，以及是否創建該作業。不能與only/ 一起使用except
job:
script: "echo Hello, Rules!"
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
when: always
- if: '$VAR =~ /pattern/'
when: manual
- when: on_success
retry
發生故障時可以自動重試作業的時間和次數。
timeout
定義自定義作業級別的超時，該超時優先於項目範圍的設置。
include
允許此作業包括外部YAML文件。也可用：include:local，include:file，include:template，和include:remote。
interruptible
定義在通過新的運行使其冗餘時是否可以取消作業。
resource_group
限製作業併發。
when
when 用於實現在發生故障或發生故障時運行的作業。
when 可以設置爲以下值之一：
on_success-僅當先前階段中的所有作業都成功（或因爲已標記，被視爲成功allow_failure）時才執行作業 。這是默認值。
on_failure -僅在前一階段中的至少一項作業失敗時才執行作業。
always -執行作業，而不管先前階段的作業狀態如何。
manual-手動執行作業（在GitLab 8.10中已添加）。在下面閱讀有關 手動操作的信息。
delayed-一定時間後執行作業（在GitLab 11.14中已添加）。在下面閱讀有關延遲動作的信息
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
when:manual
手動操作是一種特殊類型的作業，不會自動執行，需要由用戶顯式啓動。手動操作的示例用法是部署到生產環境。可以從管道，作業，環境和部署視圖開始手動操作。在環境文檔中閱讀更多
內容。手動操作可以是可選的或阻止的。阻止手動操作將在定義該操作的階段阻止管道的執行。當有人通過單擊播放按鈕執行阻止手動操作時，可以恢復管道的執行。
當管道被阻塞時，如果設置了“管道成功時合併”，則不會合並。阻塞的管道也確實具有特殊狀態，稱爲手動。使用when:manual語法時，默認情況下手動操作是非阻塞的。如果要進行手動操作阻止，則必須在中添加
allow_failure: false到作業的定義.gitlab-ci.yml。
environment
environment用於定義作業部署到特定環境。如果environment指定且不存在該名稱下的環境，則將自動創建一個新環境
environment:url
這是一個可選值，設置該值時，它將在GitLab中的不同位置顯示按鈕，單擊這些按鈕會將您帶到定義的URL。
在以下示例中，如果作業成功完成，它將在合併請求和環境/部署頁面中創建指向的按鈕
https://prod.example.com
deploy to production:
stage: deploy
script: git push production HEAD:master
environment:
name: production
url: https://prod.example.com