GitLab CI/CD 的文檔 一次看個夠 Dokcer鏡像gitlab 文檔
2485
2025-04-02
GitLab CI / CD管道配置參考 .gitlab-ci.yml文件定義字段（gitlab和github區別）
亞搏體育app文件
亞搏體育app CI / CD
Gitlab CI / CD管道配置參考
Gitlab CI / CD管道配置參考
GitLab CI/CD pipeline configuration reference
使用在每個項目中調用的YAML文件配置GitLab CI / CD 管道.gitlab-ci.yml。
該.gitlab-ci.yml文件定義管道的結構和順序，并確定：
使用GitLab Runner執行什么。
遇到特定條件時要做出什么決定。例如，當一個過程成功或失敗時。
本主題涵蓋CI / CD管道配置。有關其他CI / CD配置信息，請參閱：
GitLab CI / CD變量，用于配置運行管道的環境。
GitLab Runner高級配置，用于配置GitLab Runner。
我們有配置管道的完整示例：
有關GitLab CI / CD的快速介紹，請遵循我們的快速入門指南。
有關示例集合，請參見GitLab CI / CD示例。
要查看.gitlab-ci.yml企業中使用的大文件，請參閱的.gitlab-ci.yml文件gitlab。
有關GitLab CI / CD的其他信息：
觀看CI / CD輕松配置視頻。
在組織的 網絡廣播中觀看“ 為CI / CD辯護”，以了解CI / CD的好處以及如何衡量CI / CD自動化的結果。
了解Verizon如何 使用GitLab 將重建工作從30天減少到8小時以下。
注意： 如果您有一個 從GitLab提取鏡像的存儲庫 ，則可能需要在項目的 “設置”>“存儲庫”>“從遠程存儲庫中提取”>“觸發管道以進行鏡像更新”中 啟用管道觸發 。
介紹
管道配置從作業開始。作業是.gitlab-ci.yml文件的最基本元素。
工作是：
定義了約束，指出應在什么條件下執行它們。
具有任意名稱的頂級元素，并且必須至少包含script子句。
不限制可以定義多少個。
例如：
job1: script: "execute-script-for-job1" job2: script: "execute-script-for-job2"
1
2
3
4
5
上面的示例是具有兩個單獨作業的最簡單的CI / CD配置，其中每個作業執行一個不同的命令。當然，命令可以在存儲庫中直接執行代碼（./configure;make;make install）或運行腳本（test.sh）。
喬布斯被拾起運動員和跑步者的環境中執行。重要的是，每個作業彼此獨立運行。
驗證 .gitlab-ci.yml
GitLab CI / CD的每個實例都有一個稱為Lint的嵌入式調試工具，該工具可以驗證.gitlab-ci.yml文件的內容。您可以在ci/lint項目名稱空間頁面下找到Lint 。例如，https://gitlab.example.com/gitlab-org/project-123/-/ci/lint。
作業名稱不可用
每個作業必須具有唯一的名稱，但是有一些保留keywords名稱不能用作作業名稱：
image
services
stages
types
before_script
after_script
variables
cache
include
使用保留關鍵字
如果使用特定值（例如true或false）時出現驗證錯誤，請嘗試執行以下操作：
引用他們。
將它們更改為其他形式。例如，/bin/true。
配置參數
作業定義為定義作業行為的參數列表。
下表列出了作業的可用參數：
注： 參數 types 和 type 被 棄用 。
全局參數
必須在全局級別定義一些參數，這會影響管道中的所有作業。
全局默認值
可以使用default:關鍵字將某些參數全局設置為所有作業的默認設置 。然后可以通過特定于作業的配置覆蓋默認參數。
可以在default:塊內定義以下作業參數：
image
services
before_script
after_script
tags
cache
artifacts
retry
timeout
interruptible
在以下示例中，該ruby:2.5圖像被設置為除rspec 2.6使用該ruby:2.6圖像的作業以外的所有作業的默認圖像：
default: image: ruby:2.5 rspec: script: bundle exec rspec rspec 2.6: image: ruby:2.6 script: bundle exec rspec
1
2
3
4
5
6
7
8
9
在GitLab 12.9中引入。
您可以使用inherit:參數禁用全局定義的默認值和變量的繼承。
要啟用或禁用全部variables:或default:參數的繼承，請使用以下格式：
default: true 要么 default: false
variables: true 要么 variables: false
要僅繼承default:參數或的子集variables:，請指定要繼承的內容，未列出的任何內容均不會被繼承。使用以下格式之一：
inherit: default: [parameter1, parameter2] variables: [VARIABLE1, VARIABLE2]
1
2
3
要么：
inherit: default: - parameter1 - parameter2 variables: - VARIABLE1 - VARIABLE2
1
2
3
4
5
6
7
在以下示例中：
rubocop：
會繼承：沒有。
rspec：
將繼承：默認值image和WEBHOOK_URL變量。
會不會繼承：默認before_script和DOMAIN變量。
capybara：
將繼承：默認before_script和image。
會不會繼承：在DOMAIN和WEBHOOK_URL變量。
karma：
將繼承：默認值image和before_script，以及DOMAIN變量。
會不會繼承：WEBHOOK_URL變量。
default: image: 'ruby:2.4' before_script: - echo Hello World variables: DOMAIN: example.com WEBHOOK_URL: https://my-webhook.example.com rubocop: inherit: default: false variables: false script: bundle exec rubocop rspec: inherit: default: [image] variables: [WEBHOOK_URL] script: bundle exec rspec capybara: inherit: variables: false script: bundle exec capybara karma: inherit: default: true variables: [DOMAIN] script: karma
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
stages
stages 用于定義包含作業的階段，并為管道全局定義。
的規范stages允許具有靈活的多級管道。中的元素順序stages定義了作業執行的順序：
同一階段的作業并行運行。
前一階段的作業成功完成后，將運行下一階段的作業。
讓我們考慮以下示例，該示例定義了3個階段：
stages: - build - test - deploy
1
2
3
4
首先，的所有作業build并行執行。
如果所有作業均build成功，則這些test作業將并行執行。
如果所有作業均test成功，則這些deploy作業將并行執行。
如果所有作業均deploy成功，則將提交標記為passed。
如果先前的任何作業失敗，則將提交標記為，failed并且不執行后續作業。
還有兩個邊緣情況值得一提：
如果沒有stages被定義.gitlab-ci.yml，那么build， test和deploy允許被用作默認作業的階段。
如果作業未指定stage，則為該作業分配test階段。
workflow:rules
在GitLab 12.5中 引入
頂級workflow:密鑰適用于整個管道，并將確定是否創建管道。當前，它接受與作業中定義的rules:操作類似的單個 密鑰，從而可以動態配置管道。 rules:
如果您不熟悉GitLab CI / CD和workflow: rules，您可能會發現workflow:rules模板有用。
要定義自己的workflow: rules，當前可用的配置選項為：
if：定義規則。
when：可以設置為always或never僅設置。如果未提供，則默認值為always。
如果管道嘗試運行但不匹配任何規則，則將其刪除并且無法運行。
例如，下面的配置，管道的所有運行push事件（改變分支和新的標簽），只要它們不具有-wip在提交信息。預定管道和合并請求管道不會運行，因為沒有規則允許它們。
workflow: rules: - if: $CI_COMMIT_REF_NAME =~ /-wip$/ when: never - if: '$CI_PIPELINE_SOURCE == "push"'
1
2
3
4
5
這個例子有嚴格的規則，沒有其他管道可以運行。
或者，您可以只使用when: never規則，再使用最終when: always規則來制定寬松的規則。這允許所有類型的管道，除了那些符合when: never規則的管道：
workflow: rules: - if: '$CI_PIPELINE_SOURCE == "schedule"' when: never - if: '$CI_PIPELINE_SOURCE == "push"' when: never - when: always
1
2
3
4
5
6
7
此示例從不允許用于計劃或push（分支和標簽）管道的管道，但是在所有其他情況下都允許管道，包括合并請求管道。
與rules在job中定義的一樣，請注意不要使用允許合并請求管道和分支管道同時運行的配置，否則您可能會有重復的管道。
有用的工作流程規則條款：
在GitLab 13.0中引入。
我們提供了可與您的管道配合使用的預制模板，這些模板workflow: rules 針對常見情況進行了設置。使用這些將使事情變得容易，并防止重復的管道運行。
該Branch-Pipelines模板 使您的管道針對分支和標簽運行。
分支管道狀態將顯示在使用該分支作為源的合并請求中，但是此管道類型不支持“ 合并請求管道”提供的任何功能， 例如 “合并結果管道” 或“ 合并訓練”。如果您有意避免使用這些功能，請使用此模板。
它包括以下內容：
include: - template: 'Workflows/Branch-Pipelines.gitlab-ci.yml'
1
2
該MergeRequest-Pipelines模板 使您的管道針對默認分支（通常是master），標簽和所有類型的合并請求管道運行。如上所述，如果您使用任何“ 合并請求管道”功能，請使用此模板。
它包括以下內容：
include: - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'
1
2
include
版本歷史
Introduced in GitLab Premium 10.5.
Available for Starter, Premium and Ultimate since 10.6.
Moved to GitLab Core in 11.4.
使用include關鍵字允許包含外部YAML文件。這有助于將CI / CD配置分解為多個文件，并提高了長配置文件的可讀性。也可以將模板文件存儲在中央存儲庫中，并且項目包括其配置文件。這有助于避免重復配置，例如，所有項目的全局默認變量。
include要求外部YAML文件具有擴展名.yml或.yaml，否則將不包含外部文件。
include 支持以下包含方法：
該include方法不支持變量擴展。
注意： .gitlab-ci.yml 所有方法包括的配置都是在管道創建時評估的。該配置是及時的快照，并保留在數據庫中。 .gitlab-ci.yml 在創建下一個管道之前，對引用配置的任何更改都不會反映在GitLab中。
定義的文件include為：
與那些深深的合并.gitlab-ci.yml。
.gitlab-ci.yml無論include關鍵字的位置如何，始終首先評估并與的內容合并。
提示： 使用合并功能可以自定義和覆蓋包含本地定義的CI / CD配置。中的本地定義 .gitlab-ci.yml 將覆蓋包含的定義。
注意： 不支持在來源不同的YAML文件之間 使用 YAML錨 include 。您只能引用同一文件中的錨。您可以使用 extends關鍵字 而不是使用YAML錨。
include:local包含與相同存儲庫中的文件.gitlab-ci.yml。使用相對于根目錄（/）的完整路徑進行引用。
您只能在配置文件所在的同一分支上使用Git當前跟蹤的文件。換句話說，當使用時include:local，請確保它們.gitlab-ci.yml和本地文件都在同一分支上。
所有嵌套的包含將在同一項目的范圍內執行，因此可以使用本地，項目，遠程或模板包含。
注意： 不支持通過Git子模塊路徑包含本地文件。
例：
include: - local: '/templates/.gitlab-ci-template.yml'
1
2
提示： 本地包含可以代替未遵循的符號鏈接。
可以將其定義為簡短的本地包含：
include: '.gitlab-ci-production.yml'
1
在GitLab 11.7中引入。
要在同一GitLab實例下包含來自另一個私有項目的文件，請使用include:file。使用相對于根目錄（/）的完整路徑引用此文件。例如：
include: - project: 'my-group/my-project' file: '/templates/.gitlab-ci-template.yml'
1
2
3
您還可以指定ref，默認為HEAD項目的：
include: - project: 'my-group/my-project' ref: master file: '/templates/.gitlab-ci-template.yml' - project: 'my-group/my-project' ref: v1.0.0 file: '/templates/.gitlab-ci-template.yml' - project: 'my-group/my-project' ref: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA file: '/templates/.gitlab-ci-template.yml'
1
2
3
4
5
6
7
8
9
10
11
12
所有嵌套的包含將在目標項目的范圍內執行，因此可以使用本地（相對于目標項目），項目，遠程或模板包含。
include:remote可以用于通過HTTP / HTTPS包含來自其他位置的文件，并使用完整URL進行引用。遠程文件必須可以通過簡單的GET請求公開訪問，因為不支持遠程URL中的身份驗證模式。例如：
include: - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
1
2
所有嵌套的include將在沒有上下文的情況下作為公共用戶執行，因此僅允許另一個遠程或公共項目或模板。
在GitLab 11.7中引入。
include:template可用于包括GitLab隨附的.gitlab-ci.yml模板 。
例如：
# File sourced from GitLab's template collection include: - template: Auto-DevOps.gitlab-ci.yml
1
2
3
多個include:template文件：
include: - template: Android-Fastlane.gitlab-ci.yml - template: Auto-DevOps.gitlab-ci.yml
1
2
3
所有嵌套的包含將僅在用戶許可下執行，因此可以使用項目，遠程或模板包含。
在GitLab 11.9中引入。
嵌套包含可讓您組成一組包含。
總共允許100個include，但是重復的include被視為配置錯誤。
從GitLab 12.4開始，解析所有文件的時間限制為30秒。
有可用的其他includes示例列表。
參數詳細
以下是用于配置CI / CD管道的參數的詳細說明。
image
用于指定要用于作業的Docker映像。
對于：
簡單的定義示例，請參見Define imageand servicesfrom.gitlab-ci.yml。
詳細的使用信息，請參閱Docker集成文檔。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置image。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置image。
用于指定服務Docker映像，該映像鏈接到中指定的基本映像image。
對于：
簡單的定義示例，請參見Define imageand servicesfrom.gitlab-ci.yml。
詳細的使用信息，請參閱Docker集成文檔。
有關示例服務，請參見GitLab CI / CD服務。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置services。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置services。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置services。
一個擴展泊塢窗配置選項。
有關更多信息，請參見的可用設置services。
script
script是工作所需的唯一必需關鍵字。這是一個由Runner執行的shell腳本。例如：
job: script: "bundle exec rspec"
1
2
腳本的YAML錨可用。
此參數還可以包含使用數組的多個命令：
job: script: - uname -a - bundle exec rspec
1
2
3
4
注意： 有時， script 命令將需要用單引號或雙引號引起來。例如，包含冒號（ : ）的命令需要用引號引起來，以便YAML解析器知道將整個內容解釋為字符串而不是“鍵：值”對。使用特殊字符時要小心： : ， { ， } ， [ ， ] ， , ， & ， * ， # ， ? ， | ， - ， < ， > ， = ， ! ， % ， @ ， ` 。
如果任何腳本命令返回的退出代碼都不為零，則該作業將失敗，并且其他命令將不再執行。通過將退出代碼存儲在變量中，可以避免此行為：
job: script: - false || exit_code=$? - if [ $exit_code -ne 0 ]; then echo "Previous command failed"; fi;
1
2
3
4
在GitLab 8.7中引入，需要GitLab Runner v1.2。
before_script用于定義一個命令，該命令應在每個作業（包括部署作業）之前，但在還原所有工件之后運行。這必須是一個數組。
中指定的before_script腳本與main中指定的任何腳本串聯在一起script，并在單個shell中一起執行。
after_script用于定義將在每個作業（包括失敗的作業）之后運行的命令。這必須是一個數組。
指定的腳本在after_script新的Shell中執行，與任何腳本before_script或script腳本分開 。結果，他們：
將當前工作目錄設置回默認目錄。
無法訪問由before_script或定義的腳本所做的更改script，包括：
在script腳本中導出的命令別名和變量。
在工作樹之外進行更改（取決于Runner執行程序），例如由before_script或script腳本安裝的軟件。
有一個單獨的超時，硬編碼為5分鐘。有關詳細信息，請參見 相關問題。
不要影響作業的退出代碼。如果該script部分成功并且 after_script超時或失敗，則作業將以代碼0（Job Succeeded）退出。
可能會覆蓋全局定義的內容，before_script或者after_script 如果您按作業設置它，則可以：
default: 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
1
2
3
4
5
6
7
8
9
10
11
YAML錨before_script和after_script可用。
腳本輸出可以使用ANSI轉義碼或運行輸出ANSI轉義碼的命令或程序來著色。
例如，使用帶有顏色代碼的Bash：
job: script: - echo -e "\e[31mThis text is red,\e[0m but this text isn't\e[31m however this text is red again."
1
2
3
您可以在Shell變量甚至自定義環境變量中定義顏色代碼，這使命令更易于閱讀和重用。
例如，使用與上述相同的示例，并在中定義變量before_script：
job: before_script: - TXT_RED="\e[31m" && TXT_CLEAR="\e[0m" script: - echo -e "${TXT_RED}This text is red,${TXT_CLEAR} but this part isn't${TXT_RED} however this part is again." - echo "This text is not colored"
1
2
3
4
5
6
或使用PowerShell顏色代碼：
job: before_script: - $esc="$([char]27)"; $TXT_RED="$esc[31m"; $TXT_CLEAR="$esc[0m" script: - Write-Host $TXT_RED"This text is red,"$TXT_CLEAR" but this text isn't"$TXT_RED" however this text is red again." - Write-Host "This text is not colored"
1
2
3
4
5
6
您可以使用|（文字）和>（折疊）YAML多行塊標量指示器將長命令分成多行命令以提高可讀性。
警告： 如果將多個命令組合到一個命令字符串中，則只會報告最后一個命令的失敗或成功， 錯誤地忽略了由于bug導致的先前命令的失敗 。如果作業的成功取決于這些命令的成功或失敗，則可以將命令作為單獨的 script: 項目運行，或者 exit 1 在需要時將適當的命令添加到命令字符串中。
您可以使用|（文字上的）YAML多行塊標量指示器在script作業描述部分的多行上編寫命令。每行都被視為一個單獨的命令。在作業日志中僅重復第一個命令，但仍執行其他命令：
job: script: - | echo "First command line." echo "Second command line." echo "Third command line."
1
2
3
4
5
6
上面的示例在作業日志中呈現為：
$ echo First command line # collapsed multi-line command First command line Second command line. Third command line.
1
2
3
4
的>（折疊的）YAML多塊標量指示器對待部分作為新的命令的開始之間的空行：
job: script: - > echo "First command line is split over two lines." echo "Second command line."
1
2
3
4
5
6
7
這與編寫沒有>或|標量指示符的多行命令的行為類似：
job: script: - echo "First command line is split over two lines." echo "Second command line."
1
2
3
4
5
6
上面的兩個示例在作業日志中均顯示為：
$ echo First command line is split over two lines. # collapsed multi-line command First command line is split over two lines. Second command line.
1
2
3
當省略>或|塊標量指示符時，GitLab將通過連接非空行來形成命令，因此請確保在連接時行可以運行。
此處的 Shell 文件也可與|和>運算符一起使用 。下面的示例將小寫字母音譯為大寫字母：
job: script: - | tr a-z A-Z << END_TEXT one two three four five six END_TEXT
1
2
3
4
5
6
7
結果是：
$ tr a-z A-Z << END_TEXT # collapsed multi-line command ONE TWO THREE FOUR FIVE SIX
1
2
3
stage
stage是按職位定義的，并依賴于stages全局定義的職位。它允許將作業分為不同的階段，并且相同的作業 stage可以并行執行（取決于特定條件）。例如：
stages: - build - test - deploy job 0: stage: .pre script: make something useful before build stage job 1: stage: build script: make build dependencies job 2: stage: build script: make build artifacts job 3: stage: test script: make test job 4: stage: deploy script: make deploy job 5: stage: .post script: make something useful at the end of pipeline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
當使用自己的Runners時，默認情況下，GitLab Runner一次僅運行一個作業（ 有關更多信息，請參見Runner全局設置中的 concurrent標志）。
僅在以下情況下，作業將在您自己的跑步者上并行運行：
在不同的跑步者上運行。
跑步者的concurrent設置已更改。
在GitLab 12.4中引入。
每個管道均可使用以下階段：
.pre，這確保始終是管道的第一階段。
.post，確保始終是管道的最后階段。
用戶定義的階段在.pre之前和之后執行.post。
的順序.pre和.post也不能更改，即使在中亂序定義也是如此.gitlab-ci.yml。例如，以下是等效配置：
按順序配置：
stages: - .pre - a - b - .post
1
2
3
4
5
配置亂序：
stages: - a - .pre - b - .post
1
2
3
4
5
未明確配置：
stages: - a - b
1
2
3
注意： 如果管道僅包含 .pre 或 .post 階段中的作業，則不會創建管道。
extends
在GitLab 11.3中引入。
extends定義要使用的作業extends要繼承的條目名稱。
它是使用YAML錨點的替代方法，并且更具靈活性和可讀性：
.tests: script: rake test stage: test only: refs: - branches rspec: extends: .tests script: rake rspec only: variables: - $RSPEC
1
2
3
4
5
6
7
8
9
10
11
12
13
在上面的示例中，該rspec作業繼承自.tests模板作業。GitLab將基于密鑰執行反向深度合并。GitLab將：
將rspec內容.tests遞歸合并。
不合并鍵的值。
這將導致以下rspec工作：
rspec: script: rake rspec stage: test only: refs: - branches variables: - $RSPEC
1
2
3
4
5
6
7
8
注意： 請注意 script: rake test 已被覆蓋 script: rake rspec 。
如果確實要包含rake test，請參閱before_script和after_script。
.tests在此示例中，是一個隱藏的作業，但是也可以從常規作業中繼承。
extends支持多級繼承，但是不建議使用三個以上級別。支持的最大嵌套級別為10。以下示例具有兩個繼承級別：
.tests: only: - pushes .rspec: extends: .tests script: rake rspec rspec 1: variables: RSPEC_SUITE: '1' extends: .rspec rspec 2: variables: RSPEC_SUITE: '2' extends: .rspec spinach: extends: .tests script: rake spinach
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
在GitLab 12.0和更高版本中，還可以對使用多個父對象 extends。
extends能夠合并哈希，但不能合并數組。用于合并的算法是“最近的范圍獲勝”，因此來自最后一個成員的鍵將始終覆蓋在其他級別定義的任何內容。例如：
.only-important: variables: URL: "http://my-url.internal" IMPORTANT_VAR: "the details" only: - master - stable tags: - production script: - echo "Hello world!" .in-docker: variables: URL: "http://docker-url.internal" tags: - docker image: alpine rspec: variables: GITLAB: "is-awesome" extends: - .only-important - .in-docker script: - rake rspec
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
這將導致以下rspec工作：
rspec: variables: URL: "http://docker-url.internal" IMPORTANT_VAR: "the details" GITLAB: "is-awesome" only: - master - stable tags: - docker image: alpine script: - rake rspec
1
2
3
4
5
6
7
8
9
10
11
12
13
請注意，在上面的示例中：
variables部分已合并，但URL: "http://my-url.internal" 已被覆蓋URL: "http://docker-url.internal"。
tags: ['production']已被覆蓋tags: ['docker']。
script尚未合并，但script: ['echo "Hello world!"']已被覆蓋script: ['rake rspec']。可以使用YAML錨點合并數組。
extends與結合使用時可跨配置文件使用include。
例如，如果您有本地included.yml文件：
.template: script: - echo Hello!
1
2
3
然后，.gitlab-ci.yml您可以像這樣使用它：
include: included.yml useTemplate: image: alpine extends: .template
1
2
3
4
5
這將運行一個名為作業的作業，該作業按照作業中的定義useTemplate運行，并使用本地作業中定義的Docker映像。 echo Hello!.templatealpine
rules
在GitLab 12.3中引入。
該rules關鍵字可用于包括或管道排除作業。
規則將按順序評估，直到第一個匹配為止。匹配后，根據配置將作業包括在管道中或從管道中排除。如果包含，則作業還會 添加某些屬性。
注意： rules 不能與之組合使用， only/except 因為它是該功能的替代品。如果嘗試執行此操作，則linter返回 key may not be used with rules 錯誤。
允許的作業屬性rules為：
when：如果未定義，則默認為when: on_success。
如果用作when: delayed，start_in則也是必需的。
allow_failure：如果未定義，則默認為allow_failure: false。
如果規則評估為true，并且when除以外的其他任何值never，則該作業將包含在管道中。
例如：
docker build: script: docker build -t my-image:$CI_COMMIT_REF_SLUG . rules: - if: '$CI_COMMIT_BRANCH == "master"' when: delayed start_in: '3 hours' allow_failure: true
1
2
3
4
5
6
7
將來可能會將其他作業配置添加到規則中。如果沒有有用的東西，請打開一個問題。
可用的規則子句為：
順序評估規則，直到找到匹配項。如果找到匹配項，則檢查屬性以查看是否應將作業添加到管道。如果未定義任何屬性，則默認值為：
when: on_success
allow_failure: false
作業已添加到管道中：
如果規則相匹配，并且具有when: on_success，when: delayed或when: always。
如果沒有規則匹配，但最后一句是when: on_success，when: delayed 或when: always（無規則）。
作業未添加到管道：
如果沒有規則匹配，并沒有獨立的when: on_success，when: delayed或 when: always。
如果規則匹配，并具有when: never作為屬性。
例如，使用if子句嚴格限制作業運行的時間：
job: script: "echo Hello, Rules!" rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: manual allow_failure: true - if: '$CI_PIPELINE_SOURCE == "schedule"'
1
2
3
4
5
6
7
在此示例中：
如果管道用于合并請求，則第一個規則匹配，并且作業將添加到合并請求管道 ，其屬性為：
when: manual （體力勞動）
allow_failure: true （即使未運行手動作業，也允許管道繼續運行）
如果管道不是用于合并請求的，則第一條規則不匹配，并且第二條規則被評估。
如果管道是計劃的管道，則第二條規則匹配，并將作業添加到計劃的管道。由于未定義任何屬性，因此添加了：
when: on_success （默認）
allow_failure: false （默認）
在所有其他情況下，沒有規則匹配，因此該作業不會添加到任何其他管道。
另外，您可以定義一組規則以在某些情況下排除作業，但在所有其他情況下運行它們：
job: script: "echo Hello, Rules!" rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: never - if: '$CI_PIPELINE_SOURCE == "schedule"' when: never - when: on_success
1
2
3
4
5
6
7
8
如果管道用于合并請求，則不會將作業添加到管道。
如果管道是計劃的管道，則不會將作業添加到管道。
在所有其他情況下，都使用將該作業添加到管道中when: on_success。
注意： 如果使用 when: on_success ， always 或 delayed 作為最終規則，則可能同時啟動兩個管道。推送管道和合并請求管道都可以由同一事件觸發（對于打開的合并請求，將其推送到源分支）。見 之間的重要區別rules和only/except 了解更多詳情。
only/except默認情況下，使用定義的作業不會觸發合并請求管道。您必須明確添加only: merge_requests。
用定義的作業rules可以觸發所有類型的管道。您不必顯式配置每種類型。
例如：
job: script: "echo This creates double pipelines!" rules: - if: '$CUSTOM_VARIABLE == "false"' when: never - when: always
1
2
3
4
5
6
當此作業不運行$CUSTOM_VARIABLE是假的，但它確實在運行的所有 其他管線，包括兩個推（分支）和合并請求管道。使用此配置，每次推送到打開的合并請求的源分支都會導致重復的管道。明確允許在同一作業中同時使用推送和合并請求管道可能具有相同的效果。
我們建議使用workflow: rules來限制允許的管道類型。僅允許合并請求管道，或僅允許分支管道，可以消除重復的管道。或者，您可以使用避免最終重寫規則更嚴格，或when（always，on_success或delayed）。
另外，我們不建議將only/except作業與rules同一管道中的作業混合使用。它可能不會引起YAML錯誤，但調試確切的執行行為可以是不同的默認行為復雜，因為only/except和rules。
rules:if子句通過評估簡單if語句來確定是否將作業添加到管道。如果該if語句為true，則將作業包括在管道中或從管道中排除。用簡單的英語來說，if規則可以解釋為以下之一：
“如果此規則評估為true，則添加作業”（默認值）。
“如果該規則評估為true，則不要添加作業”（通過添加when: never）。
rules:if與only:variables每個規則只接受一個表達式字符串而不是它們的數組稍有不同。可以 使用或將任何要求值的表達式集組合為一個表達式，并使用變量匹配語法。 &&||
if:子句基于預定義環境變量 或自定義環境變量的值進行評估。
例如：
job: script: "echo Hello, Rules!" rules: - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"' when: always - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/' when: manual allow_failure: true - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME' # Checking for the presence of a variable is possible
1
2
3
4
5
6
7
8
9
有關確定when工作邏輯的一些細節：
如果提供的規則均不匹配，則將作業設置when: never為且不包含在管道中。
不帶任何條件子句的規則（例如 不帶或的whenor allow_failure規則）始終匹配，并且在達到條件時始終使用。 ifchanges
如果規則匹配且未when定義，則該規則使用when 作業的定義，on_success如果未定義，則默認為。
您可以為when每個規則定義一次，也可以在作業級別定義一次，這適用于所有規則。您不能when在工作級別使用whenin規則。
對于與only/ except關鍵字類似的行為，您可以檢查$CI_PIPELINE_SOURCE變量的值：
例如：
job: script: "echo Hello, Rules!" rules: - if: '$CI_PIPELINE_SOURCE == "schedule"' when: manual allow_failure: true - if: '$CI_PIPELINE_SOURCE == "push"'
1
2
3
4
5
6
7
本示例在計劃管道或推送管道（到分支或標簽）中使用when: on_success（默認）將作業作為手動作業運行。不會將作業添加到任何其他管道類型。
另一個例子：
job: script: "echo Hello, Rules!" rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_PIPELINE_SOURCE == "schedule"'
1
2
3
4
5
本示例將作業作為合并請求管道 和計劃管道中的when: on_success作業運行。它不能在任何其他管道類型中運行。
if子句的其他常用變量：
if: $CI_COMMIT_TAG：如果為標簽推送更改。
if: $CI_COMMIT_BRANCH：如果將更改推送到任何分支。
if: '$CI_COMMIT_BRANCH == "master"'：如果將更改推送到master。
if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'：如果將更改推送到默認分支（通常為master）。如果在可能具有不同默認分支的多個項目中重用同一配置，則很有用。
if: '$CI_COMMIT_BRANCH =~ /regex-expression/'：如果commit分支與正則表達式匹配。
if: '$CUSTOM_VARIABLE !~ /regex-expression/'：如果自定義變量 CUSTOM_VARIABLE并沒有匹配的正則表達式。
if: '$CUSTOM_VARIABLE == "value1"'：如果自定義變量CUSTOM_VARIABLE是value1。
為了避免在創建分支而未進行任何更改時運行管道，請檢查的值$CI_COMMIT_BEFORE_SHA。其值為 0000000000000000000000000000000000000000：
在沒有提交的分支中。
在標記管道和計劃管道中。如果您不想跳過這些規則，則應將其定義得非常狹窄。
要跳過所有空分支上的管道，還要跳過標簽和時間表：
rules: - if: $CI_COMMIT_BEFORE_SHA == '0000000000000000000000000000000000000000' when: never
1
2
3
要在分支為空時跳過分支管道：
rules: - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BEFORE_SHA != '0000000000000000000000000000000000000000'
1
2
為了確定是否應將作業添加到管道，rules: changes子句會檢查由Git push事件更改的文件。
rules: changes的工作方式與only: changes和except: changes完全相同，接受路徑數組。同樣，如果沒有Git推送事件，則始終返回true。它僅應用于分支管道或合并請求管道。
例如：
workflow: rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' docker build: script: docker build -t my-image:$CI_COMMIT_REF_SLUG . rules: - changes: - Dockerfile when: manual allow_failure: true
1
2
3
4
5
6
7
8
9
10
11
在此示例中：
workflow: rules 僅允許管道用于所有作業的合并請求。
如果Dockerfile已更改，則將該作業作為手動作業添加到管道中，并允許管道繼續運行，即使未觸發該作業（allow_failure: true）。
如果Dockerfile尚未更改，請不要將作業添加到任何管道（與相同when: never）。
在GitLab 12.4中引入。
exists 接受路徑數組，如果其中任何一個路徑作為存儲庫中的文件存在，則將匹配。
例如：
job: script: docker build -t my-image:$CI_COMMIT_REF_SLUG . rules: - exists: - Dockerfile
1
2
3
4
5
您還可以使用全局模式來匹配存儲庫中任何目錄中的多個文件。
例如：
job: script: bundle exec rspec rules: - exists: - spec/**.rb
1
2
3
4
5
注意： 出于性能原因， exists 與模式一起使用限制為10000個檢查。第10000次檢查后，帶有圖案化球形的規則將始終匹配。
在GitLab 12.8中引入。
您可以allow_failure: true在rules:不停止管道本身的情況下使用來允許作業失敗或手動作業等待操作。未定義使用rules:默認為allow_failure: false if的所有作業allow_failure:。
規則級rules:allow_failure選項將覆蓋作業級 allow_failure選項，并且僅在作業由特定規則觸發時才應用。
job: script: "echo Hello, Rules!" rules: - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"' when: manual allow_failure: true
1
2
3
4
5
6
在此示例中，如果第一個規則匹配，則作業將具有when: manual和allow_failure: true。
要合相if，changes以及exists與AND子句，在相同的規則中使用它們。
在以下示例中：
如果Dockerfile或中的任何文件docker/scripts/ 更改了AND，我們將手動運行該作業$VAR == "string value"。
否則，該作業將不會包含在管道中。
docker build: script: docker build -t my-image:$CI_COMMIT_REF_SLUG . rules: - if: '$VAR == "string value"' changes: # Will include the job and set to when:manual if any of the follow paths match a modified file. - Dockerfile - docker/scripts/* when: manual # - when: never would be redundant here, this is implied any time rules are listed.
1
2
3
4
5
6
7
8
9
諸如branches或之refs類的當前可用于 only/的關鍵字except尚不可用，rules因為在這種情況下，它們的用法和行為正在被單獨考慮。我們的史詩rules中正在討論未來的關鍵字改進，以改進，任何人都可以添加建議或請求。
only/ except（基本）
注： 該 rules 語法定義時，工作應該運行與否的改進，功能更強大的解決方案。考慮使用 rules 而不是來 only/except 充分利用管道。
only和except是兩個參數，用于設置作業策略以限制創建作業的時間：
only 定義將為其運行作業的分支和標簽的名稱。
except定義將不運行作業的分支和標簽的名稱 。
有一些適用于作業策略的規則：
only并且except具有包容性。如果作業規范中同時定義了only和except，則ref將由only和過濾except。
only并except允許使用正則表達式（受支持的regexp語法）。
only并except允許指定存儲庫路徑以過濾派生作業。
另外，only并except允許使用特殊關鍵字：
在以下示例中，job將僅對以開頭的引用運行issue-，而所有分支都將被跳過：
job: # use regexp only: - /^issue-.*$/ # use special keyword except: - branches
1
2
3
4
5
6
7
模式匹配默認情況下區分大小寫。使用i標志修飾符，例如 /pattern/i使模式不區分大小寫：
job: # use regexp only: - /^issue-.*$/i # use special keyword except: - branches
1
2
3
4
5
6
7
在此示例中，job將僅對帶標簽的引用運行，或者通過API觸發器或管道時間表顯式請求構建時運行：
job: # use special keywords only: - tags - triggers - schedules
1
2
3
4
5
6
存儲庫路徑可用于僅對父存儲庫執行作業，而不能用于派生：
job: only: - branches@gitlab-org/gitlab except: - master@gitlab-org/gitlab - /^release/.*$/@gitlab-org/gitlab
1
2
3
4
5
6
上面的示例將在上job的所有分支上運行gitlab-org/gitlab，但master名稱以開頭的分支除外release/。
如果作業沒有only規則，only: ['branches', 'tags']則默認設置。如果沒有except規則，則為空。
例如，
job: script: echo 'test'
1
2
轉換為：
job: script: echo 'test' only: ['branches', 'tags']
1
2
3
因為@用于表示ref的存儲庫路徑的開頭，所以匹配包含@正則表達式中字符的ref名稱需要使用十六進制字符代碼match \x40。
正則表達式只能匹配標簽或分支名稱。如果給定存儲庫路徑，則始終在字面上匹配。
如果將使用正則表達式匹配標記或分支名稱，則模式的整個ref名稱部分必須是正則表達式，并且必須用包圍/。（在結束符后附加正則表達式標志/。）因此issue-/.*/無法匹配以開頭的所有標記名或分支名issue-。
提示： 使用定位符 ^ 和 $ 避免正則表達式僅匹配標記名稱或分支名稱的子字符串。例如， /^issue-.*$/ 等于 /^issue-/ ，而just /issue/ 還要匹配名為的分支 severe-issues 。
警告： 這是GitLab 11.9.4引入的重大更改。
在GitLab 11.9.4中，GitLab開始在內部將用于only和except參數的regexp轉換為RE2。
這意味著僅 支持Ruby Regexp提供的功能子集。由于計算復雜性，RE2限制了所提供的功能集，這意味著某些功能在GitLab 11.9.4中變得不可用。例如，負面的前瞻。
對于從11.9.7到GitLab 12.0的GitLab版本，GitLab提供了一個功能標記，管理員可以啟用它，從而允許用戶使用不安全的regexp語法。這帶來了與以前允許的語法版本的兼容性，并允許用戶正常遷移到新語法。
Feature.enable(:allow_unsafe_ruby_regexp)
1
only/ except（高級）
警告： 這是 Alpha版 功能，如有更改，恕不另行通知！
GitLab支持簡單策略和復雜策略，因此可以使用數組和哈希配置方案。
有四個鍵可用：
refs
variables
changes
kubernetes
如果在only或下使用多個鍵except，則這些鍵將作為單個聯合表達式求值。那是：
only: 表示“如果所有條件都匹配，則包括此作業”。
except: 表示“如果滿足任何條件，則排除此工作”。
使用only，各個鍵在邏輯上由AND連接：
（任何參考）AND（任何變量）AND（任何變化）AND（如果Kubernetes是活動的）
在以下示例中，當滿足以下所有條件時，test將only創建作業：
管道已預定 或正在運行master。
該variables關鍵字匹配。
該kubernetes服務在項目上處于活動狀態。
test: script: npm run test only: refs: - master - schedules variables: - $CI_COMMIT_MESSAGE =~ /run-end-to-end-tests/ kubernetes: active
1
2
3
4
5
6
7
8
9
except 被實現為對此完整表達式的否定：
NOT（（任何參考）AND（任何變量）AND（任何變化）AND（如果Kubernetes處于活動狀態））
這意味著將鍵視為由OR聯接。這種關系可以描述為：
（任何參考）或（任何變量）或（任何變化）或（如果Kubernetes處于活動狀態）
在以下示例中，如果滿足以下任一條件，test則不會創建作業：
管道運行在master。
README.md存儲庫的根目錄中的文件已更改。
test: script: npm run test except: refs: - master changes: - "README.md"
1
2
3
4
5
6
7
refs GitLab 10.0中引入的策略。
該refs策略可以采用與簡化的唯一/例外配置相同的值 。
在下面的示例中，deploy僅在為分支計劃了管道或為管道運行時才創建作業master：
deploy: only: refs: - master - schedules
1
2
3
4
5
kubernetes GitLab 10.0中引入的策略。
Git GitHub
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
