本文檔列出了 GitLab?.gitlab-ci.yml?文件的配置選項(xiàng)。
- 有關(guān) GitLab CI/CD 的快速介紹，請(qǐng)遵循快速入門(mén)指南。
- 有關(guān)示例集合，請(qǐng)參閱 GitLab CI/CD 示例。
- 要查看企業(yè)使用的大型?
.gitlab-ci.yml?文件，請(qǐng)參閱gitlab的.gitlab-ci.yml文件。
當(dāng)在編輯您的?.gitlab-ci.yml?文件時(shí)，可以使用?CI Lint?工具來(lái)驗(yàn)證它。
關(guān)鍵字
GitLab CI/CD 流水線配置包括：
-
配置流水線行為的全局關(guān)鍵字：
關(guān)鍵字 描述 default 作業(yè)關(guān)鍵字的自定義默認(rèn)值。 stages 流水線階段的名稱(chēng)和順序。 workflow 控制運(yùn)行的流水線類(lèi)型。 include 從其他 YAML 文件導(dǎo)入配置。 -
作業(yè)由作業(yè)關(guān)鍵字配置：
| 關(guān)鍵字 | 描述 |
|---|---|
| after_script | 覆蓋作業(yè)后執(zhí)行的一組命令。 |
| allow_failure | 允許作業(yè)失敗。失敗的作業(yè)不會(huì)導(dǎo)致流水線失敗。 |
| artifacts | 成功時(shí)附加到作業(yè)的文件和目錄列表。 |
| before_script | 覆蓋在作業(yè)之前執(zhí)行的一組命令。 |
| cache | 應(yīng)在后續(xù)運(yùn)行之間緩存的文件列表。 |
| coverage | 給定作業(yè)的代碼覆蓋率設(shè)置。 |
| dast_configuration | 在作業(yè)級(jí)別使用來(lái)自 DAST 配置文件的配置。 |
| dependencies | 通過(guò)提供要從中獲取產(chǎn)物的作業(yè)列表，來(lái)限制將哪些產(chǎn)物傳遞給特定作業(yè)。 |
| environment | 作業(yè)部署到的環(huán)境的名稱(chēng)。 |
| except | 控制何時(shí)不創(chuàng)建作業(yè)。 |
| extends | 此作業(yè)繼承自的配置條目。 |
| image | 使用 Docker 鏡像。 |
| inherit | 選擇所有作業(yè)繼承的全局默認(rèn)值。 |
| interruptible | 定義當(dāng)新運(yùn)行使作業(yè)變得多余時(shí)，是否可以取消作業(yè)。 |
| needs | 在 stage 順序之前執(zhí)行的作業(yè)。 |
| only | 控制何時(shí)創(chuàng)建作業(yè)。 |
| pages | 上傳作業(yè)的結(jié)果，與 GitLab Pages 一起使用。 |
| parallel | 應(yīng)該并行運(yùn)行多少個(gè)作業(yè)實(shí)例。 |
| release | 指示運(yùn)行器生成 release 對(duì)象。 |
| resource_group | 限制作業(yè)并發(fā)。 |
| retry | 在失敗的情況下可以自動(dòng)重試作業(yè)的時(shí)間和次數(shù)。 |
| rules | 用于評(píng)估和確定作業(yè)的選定屬性以及它是否已創(chuàng)建的條件列表。 |
| script | 由 runner 執(zhí)行的 Shell 腳本。 |
| secrets | 作業(yè)所需的 CI/CD secret 信息。 |
| services | 使用 Docker 服務(wù)鏡像。 |
| stage | 定義作業(yè)階段。 |
| tags | 用于選擇 runner 的標(biāo)簽列表。 |
| timeout | 定義優(yōu)先于項(xiàng)目范圍設(shè)置的自定義作業(yè)級(jí)別超時(shí)。 |
| trigger | 定義下游流水線觸發(fā)器。 |
| variables | 在作業(yè)級(jí)別定義作業(yè)變量。 |
| when | 何時(shí)運(yùn)行作業(yè)。 |
全局關(guān)鍵字
某些關(guān)鍵字未在作業(yè)中定義。這些關(guān)鍵字控制流水線行為或?qū)腩~外的流水線配置。
default
您可以為某些關(guān)鍵字設(shè)置全局默認(rèn)值。 未定義一個(gè)或多個(gè)所列關(guān)鍵字的作業(yè)使用在?default:?部分中定義的值。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：以下關(guān)鍵字可以具有自定義默認(rèn)值：
- after_script
- artifacts
- before_script
- cache
- image
- interruptible
- retry
- services
- tags
- timeout
default:
image: ruby:3.0
rspec:
script: bundle exec rspec
rspec 2.7:
image: ruby:2.7
script: bundle exec rspec示例將?ruby:3.0?鏡像設(shè)置為流水線中所有作業(yè)的默認(rèn)鏡像。?rspec 2.7?作業(yè)不使用默認(rèn)值，因?yàn)樗褂锰囟ㄓ谧鳂I(yè)的?image:?部分覆蓋了默認(rèn)值：
額外細(xì)節(jié)：
- 創(chuàng)建流水線時(shí)，每個(gè)默認(rèn)值都會(huì)復(fù)制到所有未定義該關(guān)鍵字的作業(yè)。
- 如果作業(yè)已經(jīng)配置了其中一個(gè)關(guān)鍵字，則作業(yè)中的配置優(yōu)先，不會(huì)被默認(rèn)替換。
- 使用?inherit:default?控制作業(yè)中默認(rèn)關(guān)鍵字的繼承。
stages
使用?stages?來(lái)定義包含作業(yè)組的階段。stages?是為流水線全局定義的。在作業(yè)中使用?stage?來(lái)定義作業(yè)屬于哪個(gè)階段。
如果?.gitlab-ci.yml?文件中沒(méi)有定義?stages，那么默認(rèn)的流水線階段是：
- .pre
buildtestdeploy- .post
stages?項(xiàng)的順序定義了作業(yè)的執(zhí)行順序：
- 同一階段的作業(yè)并行運(yùn)行。
- 下一階段的作業(yè)在上一階段的作業(yè)成功完成后運(yùn)行。
例如：
stages:
- build
- test
- deploy-
build?中的所有作業(yè)并行執(zhí)行。 - 如果?
build?中的所有作業(yè)都成功，test?作業(yè)將并行執(zhí)行。 - 如果?
test?中的所有作業(yè)都成功，deploy?作業(yè)將并行執(zhí)行。 - 如果?
deploy?中的所有作業(yè)都成功，則流水線被標(biāo)記為?passed。
如果任何作業(yè)失敗，流水線將被標(biāo)記為?failed?并且后續(xù)階段的作業(yè)不會(huì)啟動(dòng)。當(dāng)前階段的作業(yè)不會(huì)停止并繼續(xù)運(yùn)行。
如果作業(yè)未指定?stage，則作業(yè)被分配到?test?階段。
如果定義了一個(gè)階段，但沒(méi)有作業(yè)使用它，則該階段在流水線中不可見(jiàn)。 這對(duì)合規(guī)流水線配置很有用，因?yàn)椋?/p>
- 階段可以在合規(guī)性配置中定義，但如果不使用則保持隱藏。
- 當(dāng)開(kāi)發(fā)人員在作業(yè)定義中使用它們時(shí)，定義的階段變得可見(jiàn)。
要使作業(yè)更早開(kāi)始并忽略階段順序，請(qǐng)使用?needs?關(guān)鍵字。
workflow
使用?workflow:?來(lái)確定是否創(chuàng)建流水線。 在頂層定義此關(guān)鍵字，使用單個(gè)?rules:?關(guān)鍵字，類(lèi)似于在作業(yè)中定義的?rules:。
workflow:rules
您可以使用?workflow:rules?模板 導(dǎo)入預(yù)先配置的?workflow:rules?條目。
workflow: rules?接受這些關(guān)鍵字：
- if：檢查此規(guī)則以確定何時(shí)運(yùn)行流水線。
-
when：指定當(dāng)?
if?規(guī)則為 true 時(shí)要做什么。- 要運(yùn)行流水線，請(qǐng)?jiān)O(shè)置為?
always。 - 要阻止流水線運(yùn)行，請(qǐng)?jiān)O(shè)置為?
never。
- 要運(yùn)行流水線，請(qǐng)?jiān)O(shè)置為?
- variables：如果未定義，則使用在別處定義的變量。
當(dāng)沒(méi)有規(guī)則為 true 時(shí)，流水線不會(huì)運(yùn)行。
workflow: rules?的一些示例?if?子句如下：
| 示例規(guī)則 | 詳細(xì)信息 |
|---|---|
if: '$CI_PIPELINE_SOURCE == "merge_request_event"' |
控制合并請(qǐng)求流水線何時(shí)運(yùn)行。 |
if: '$CI_PIPELINE_SOURCE == "push"' |
控制分支流水線和標(biāo)簽流水線何時(shí)運(yùn)行。 |
if: $CI_COMMIT_TAG |
控制標(biāo)簽流水線何時(shí)運(yùn)行。 |
if: $CI_COMMIT_BRANCH |
控制分支流水線何時(shí)運(yùn)行。 |
在此示例中，如果提交標(biāo)題（提交消息的第一行）不以?-draft?結(jié)尾并且流水線用于以下任一情況，則流水線運(yùn)行：
workflow:
rules:
- if: $CI_COMMIT_TITLE =~ /-draft$/
when: never
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH- 合并請(qǐng)求
- 默認(rèn)分支
這個(gè)例子有嚴(yán)格的規(guī)則，流水線在任何其他情況下都不運(yùn)行。
或者，所有規(guī)則都可以是?when: never，最后是?when:always?規(guī)則。匹配?when: never?規(guī)則的流水線不會(huì)運(yùn)行。 所有其他流水線類(lèi)型運(yùn)行：
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: never
- if: '$CI_PIPELINE_SOURCE == "push"'
when: never
- when: always此示例阻止了計(jì)劃或?push（分支和標(biāo)簽）的流水線。 最后的?when: always?規(guī)則運(yùn)行所有其他流水線類(lèi)型，包括合并請(qǐng)求流水線。
如果您的規(guī)則同時(shí)匹配分支流水線和合并請(qǐng)求流水線，則可能會(huì)出現(xiàn)重復(fù)流水線。
workflow:rules:variables
- 引入于 13.11 版本
- 功能標(biāo)志移除于 14.1 版本。
您可以在?workflow:rules:?中使用?variables?來(lái)定義特定流水線條件的變量。
當(dāng)條件匹配時(shí)，將創(chuàng)建該變量并可供流水線中的所有作業(yè)使用。如果該變量已在全局級(jí)別定義，則?workflow?變量?jī)?yōu)先并覆蓋全局變量。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：變量名和值對(duì)：
- 名稱(chēng)只能使用數(shù)字、字母和下劃線 (
_)。 - 值必須是字符串。
workflow:rules:variables?示例：
variables:
DEPLOY_VARIABLE: "default-deploy"
workflow:
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables:
DEPLOY_VARIABLE: "deploy-production" # Override globally-defined DEPLOY_VARIABLE
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # Define a new variable.
- when: always # Run the pipeline in other cases
job1:
variables:
DEPLOY_VARIABLE: "job1-default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # Override DEPLOY_VARIABLE defined
DEPLOY_VARIABLE: "job1-deploy-production" # at the job level.
- when: on_success # Run the job in other cases
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"
job2:
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"當(dāng)分支是默認(rèn)分支時(shí)：
- job1 的?
DEPLOY_VARIABLE?是?job1-deploy-production。 - job2 的?
DEPLOY_VARIABLE?是?deploy-production。
當(dāng)分支是?feature?時(shí)：
- job1 的?
DEPLOY_VARIABLE?是?job1-default-deploy，而?IS_A_FEATURE?是true。 - job2 的?
DEPLOY_VARIABLE?是?default-deploy，而?IS_A_FEATURE?是true。
當(dāng)分支是別的東西時(shí)：
- job1 的?
DEPLOY_VARIABLE?是?job1-default-deploy。 - job2 的?
DEPLOY_VARIABLE?是?default-deploy。
include
使用?include?在 CI/CD 配置中包含外部 YAML 文件。 您可以將一個(gè)長(zhǎng)的?.gitlab-ci.yml?文件拆分為多個(gè)文件以提高可讀性，或減少同一配置在多個(gè)位置的重復(fù)。
您還可以將模板文件存儲(chǔ)在中央倉(cāng)庫(kù)中并將它們包含在項(xiàng)目中。
include?文件：
- 與?
.gitlab-ci.yml?文件中的那些合并。 - 無(wú)論?
include?關(guān)鍵字的位置如何，始終先求值，然后與?.gitlab-ci.yml?文件的內(nèi)容合并。
您可以?nest?最多 100 個(gè) include，在 14.9 及更高版本中，同一個(gè)文件可以在 nested includes 中多次 include，但重復(fù)的將被忽略。 在 12.4 及更高版本中，解析所有文件的時(shí)間限制為 30 秒。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：include?子鍵：
- include:local
- include:file
- include:remote
- include:template
額外細(xì)節(jié)：
- 使用合并來(lái)自定義和覆蓋本地包含的 CI/CD 配置。
- 您可以通過(guò)在?
.gitlab-ci.yml?文件中使用相同的作業(yè)名稱(chēng)或全局關(guān)鍵字，來(lái)覆蓋包含的配置。這兩個(gè)配置合并在一起，.gitlab-ci.yml?文件中的配置優(yōu)先于包含的配置。
include:local
使用?include:local?包含與?.gitlab-ci.yml?文件位于同一倉(cāng)庫(kù)中的文件。 使用?include:local?代替符號(hào)鏈接。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：
- 相對(duì)于根目錄 (
/) 的完整路徑。 - YAML 文件的擴(kuò)展名必須是?
.yml?或?.yaml。 - 您可以在文件路徑中使用?*?和?**?通配符。
include:local?示例：
include:
- local: '/templates/.gitlab-ci-template.yml'您還可以使用較短的語(yǔ)法來(lái)定義路徑：
include: '.gitlab-ci-production.yml'額外細(xì)節(jié)：
-
.gitlab-ci.yml?文件和本地文件必須在同一個(gè)分支上。 - 您不能通過(guò) Git 子模塊路徑包含本地文件。
- 所有的?nested includes?都在同一個(gè)項(xiàng)目范圍內(nèi)執(zhí)行，所以您可以使用本地、項(xiàng)目、遠(yuǎn)端或模板 include。
include:file
包含來(lái)自同一項(xiàng)目的多個(gè)文件引入于 13.6 版本。功能標(biāo)志移除于 13.8 版本。
要在同一個(gè)實(shí)例上包含來(lái)自另一個(gè)私有項(xiàng)目的文件，請(qǐng)使用?include:file。 您只能將?include:file?與?include:project?結(jié)合使用。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：相對(duì)于根目錄 (/) 的完整路徑。YAML 文件的擴(kuò)展名必須是.yml?或.yaml。
include:file?示例：
include:
- project: 'my-group/my-project'
file: '/templates/.gitlab-ci-template.yml'您還可以指定一個(gè)?ref。 如果不指定值，則 ref 默認(rèn)為項(xiàng)目的?HEAD：
include:
- project: 'my-group/my-project'
ref: main
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: v1.0.0 # Git Tag
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA
file: '/templates/.gitlab-ci-template.yml'您可以包含來(lái)自同一項(xiàng)目的多個(gè)文件：
include:
- project: 'my-group/my-project'
ref: main
file:
- '/templates/.builds.yml'
- '/templates/.tests.yml'額外細(xì)節(jié)：
- 所有?nested includes?都在目標(biāo)項(xiàng)目的范圍內(nèi)執(zhí)行。您可以使用?
local（相對(duì)于目標(biāo)項(xiàng)目）、project、remote?或?template?include。 - 當(dāng)流水線啟動(dòng)時(shí)，評(píng)估所有方法 include 的?
.gitlab-ci.yml?文件配置。配置是一個(gè)及時(shí)的快照并持久存在于數(shù)據(jù)庫(kù)中。在下一個(gè)流水線啟動(dòng)之前，系統(tǒng)不會(huì)反映對(duì)引用的?.gitlab-ci.yml?文件配置的任何更改。 - 當(dāng)您包含來(lái)自另一個(gè)私有項(xiàng)目的 YAML 文件時(shí)，運(yùn)行流水線的用戶必須是這兩個(gè)項(xiàng)目的成員并且具有運(yùn)行流水線的適當(dāng)權(quán)限。如果用戶無(wú)權(quán)訪問(wèn)任何包含的文件，則可能會(huì)顯示?
not found or access denied?錯(cuò)誤。
include:remote
使用帶有完整 URL 的?include:remote?來(lái)包含來(lái)自不同位置的文件。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：可通過(guò) HTTP/HTTPS?GET?請(qǐng)求訪問(wèn)的公共 URL。不支持使用遠(yuǎn)端 URL 進(jìn)行身份驗(yàn)證。
YAML 文件的擴(kuò)展名必須是?.yml?或?.yaml。
include:remote?示例：
include:
- remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'額外細(xì)節(jié)：
- 所有?nested includes?都以公共用戶身份在沒(méi)有上下文的情況下執(zhí)行，因此您只能包含公共項(xiàng)目或模板。
- 包含遠(yuǎn)端 CI/CD 配置文件時(shí)要小心。當(dāng)外部 CI/CD 配置文件更改時(shí)，不會(huì)觸發(fā)任何流水線或通知。從安全角度來(lái)看，這類(lèi)似于拉取第三方依賴項(xiàng)。
include:template
使用?include:template?包含?.gitlab-ci.yml?模板。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。
可能的輸入：.gitlab-ci.yml?模板.
include:template?示例：
# File sourced from the GitLab template collection
include:
- template: Auto-DevOps.gitlab-ci.yml多個(gè)?include:template?文件：
include:
- template: Android-Fastlane.gitlab-ci.yml
- template: Auto-DevOps.gitlab-ci.yml額外細(xì)節(jié)：
- 所有?nested includes?僅在用戶許可的情況下執(zhí)行，因此可以使用?
project、remote?或?template?include。
作業(yè)關(guān)鍵字
以下主題說(shuō)明如何使用關(guān)鍵字來(lái)配置 CI/CD 流水線。
image
使用?image?指定運(yùn)行作業(yè)的 Docker 鏡像。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：鏡像的名稱(chēng)，包括鏡像庫(kù)路徑（如果需要），采用以下格式之一：
-
<image-name>（與使用帶有?latest?標(biāo)簽的?<image-name>?相同） <image-name>:<tag><image-name>@<digest>
image?示例：
default:
image: ruby:3.0
rspec:
script: bundle exec rspec
rspec 2.7:
image: registry.example.com/my-group/my-project/ruby:2.7
script: bundle exec rspec在這個(gè)例子中，ruby:3.0?鏡像是流水線中所有作業(yè)的默認(rèn)鏡像。?rspec 2.7?作業(yè)不使用默認(rèn)值，因?yàn)樗褂锰囟ㄓ谧鳂I(yè)的?image:?部分覆蓋了默認(rèn)值。
image:name
作業(yè)運(yùn)行所在的 Docker 鏡像的名稱(chēng)。與自身使用的?image:?類(lèi)似。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：鏡像的名稱(chēng)，包括鏡像庫(kù)路徑（如果需要），采用以下格式之一：
-
<image-name>（與使用帶有?latest?標(biāo)簽的?<image-name>?相同） <image-name>:<tag><image-name>@<digest>
image:name?示例：
image:
name: "registry.example.com/my/image:latest"image:pull_policy
- 引入于 15.1 版本，功能標(biāo)志為?
ci_docker_image_pull_policy。默認(rèn)禁用。- 需要極狐GitLab Runner 15.1 或更高版本。
FLAG: 在私有化部署版上，此功能默認(rèn)不可用。要使其可用，詢問(wèn)管理員啟用功能標(biāo)志?ci_docker_image_pull_policy。此功能尚未準(zhǔn)備好用于生產(chǎn)用途。
Runner 用于獲取 Docker 鏡像的拉取策略。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default?部分中使用。
可能的輸入：
- 單個(gè)拉取策略或數(shù)組中的多個(gè)拉取策略?？梢允?
always、if-not-present?或?never。
image:pull_policy?示例：
job1:
script: echo "A single pull policy."
image:
name: ruby:3.0
pull_policy: if-not-present
job2:
script: echo "Multiple pull policies."
image:
name: ruby:3.0
pull_policy: [always, if-not-present]額外細(xì)節(jié)：
- 如果 runner 不支持定義的拉取策略，則作業(yè)將失敗并出現(xiàn)類(lèi)似以下錯(cuò)誤：
ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])。
image:entrypoint
作為容器入口點(diǎn)執(zhí)行的命令或腳本。
創(chuàng)建 Docker 容器時(shí)，entrypoint?被轉(zhuǎn)換為 Docker 的?--entrypoint?選項(xiàng)。 語(yǔ)法類(lèi)似于?Dockerfile?ENTRYPOINT?指令，其中每個(gè) shell 令牌都是數(shù)組中的一個(gè)單獨(dú)字符串。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：一個(gè)字符串。
image:entrypoint?示例：
image:
name: super/sql:experimental
entrypoint: [""]services
使用?services?指定一個(gè)額外的 Docker 鏡像來(lái)運(yùn)行腳本。services?鏡像鏈接到?image?關(guān)鍵字中指定的鏡像。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：服務(wù)鏡像的名稱(chēng)，包括鏡像庫(kù)路徑（如果需要），采用以下格式之一：
-
<image-name>（與使用帶有?latest?標(biāo)簽的?<image-name>?相同） <image-name>:<tag><image-name>@<digest>
services?示例：
default:
image:
name: ruby:2.6
entrypoint: ["/bin/bash"]
services:
- name: my-postgres:11.7
alias: db-postgres
entrypoint: ["/usr/local/bin/db-postgres"]
command: ["start"]
before_script:
- bundle install
test:
script:
- bundle exec rake spec在此示例中，作業(yè)啟動(dòng)一個(gè) Ruby 容器。然后，該作業(yè)從該容器啟動(dòng)另一個(gè)運(yùn)行 PostgreSQL 的容器。然后該作業(yè)在該容器中運(yùn)行腳本。
service:pull_policy
- 引入于 15.1 版本，功能標(biāo)志為?
ci_docker_image_pull_policy。默認(rèn)禁用。- 在 SaaS 版和私有化部署版上啟用于 15.2 版本。
- 需要極狐GitLab Runner 15.1 或更高版本。
Runner 用于獲取 Docker 鏡像的拉取策略。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default?部分中使用。
可能的輸入：
- 單個(gè)拉取策略，或數(shù)組中的多個(gè)拉取策略?？梢允?
always、if-not-present?或?never。
service:pull_policy?的示例：
job1:
script: echo "A single pull policy."
services:
- name: postgres:11.6
pull_policy: if-not-present
job2:
script: echo "Multiple pull policies."
services:
- name: postgres:11.6
pull_policy: [always, if-not-present]額外細(xì)節(jié)：
- 如果 runner 不支持定義的拉取策略，則作業(yè)將失敗并出現(xiàn)類(lèi)似的錯(cuò)誤：
ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])。
script
使用?script?指定 runner 要執(zhí)行的命令。
除了?trigger jobs?之外的所有作業(yè)都需要一個(gè)?script?關(guān)鍵字。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：一個(gè)數(shù)組，包括：
- 單行命令。
- 長(zhǎng)命令拆分多行。
- YAML 錨點(diǎn)。
script?示例：
job1:
script: "bundle exec rspec"
job2:
script:
- uname -a
- bundle exec rspec額外細(xì)節(jié)：
- 當(dāng)您使用?script?中的這些特殊字符時(shí)，必須使用單引號(hào) (
') 或雙引號(hào) (")。
before_script
使用?before_script?來(lái)定義一系列命令，這些命令應(yīng)該在每個(gè)作業(yè)的?script?命令之前運(yùn)行，但在?artifacts?恢復(fù)之后。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：一個(gè)數(shù)組，包括：
- 單行命令。
- 長(zhǎng)命令拆分多行。
- YAML 錨點(diǎn)。
before_script?示例：
job:
before_script:
- echo "Execute this command before any 'script:' commands."
script:
- echo "This command executes after the job's 'before_script' commands."額外細(xì)節(jié)：
- 您在?
before_script?中指定的腳本與您在主?script?中指定的任何腳本連接在一起。組合腳本在單個(gè) shell 中一起執(zhí)行。 - 在頂層使用?
before_script，但不在?default?部分，已棄用。
after_script
使用?after_script?定義在每個(gè)作業(yè)之后運(yùn)行的命令數(shù)組，包括失敗的作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：一個(gè)數(shù)組，包括：
- 單行命令。
- 長(zhǎng)命令拆分多行。
- YAML 錨點(diǎn)。
Example of?after_script:
job:
script:
- echo "An example script section."
after_script:
- echo "Execute this command after the `script` section completes."額外細(xì)節(jié)：
您在?after_script?中指定的腳本在一個(gè)新的 shell 中執(zhí)行，與任何?before_script?或?script?命令分開(kāi)。結(jié)果：
- 將當(dāng)前工作目錄設(shè)置回默認(rèn)值（根據(jù)定義運(yùn)行程序如何處理 Git 請(qǐng)求的變量）。
- 無(wú)權(quán)訪問(wèn)由?
before_script?或?script?中定義的命令完成的更改，包括：- 在
script?腳本中導(dǎo)出的命令別名和變量。 - 作業(yè)樹(shù)之外的更改（取決于 runner），例如由?
before_script?或?script?腳本安裝的軟件。
- 在
- 有一個(gè)單獨(dú)的超時(shí)，它被硬編碼為 5 分鐘。
- 不要影響作業(yè)的退出代碼。如果?
script?部分成功并且?after_script?超時(shí)或失敗，作業(yè)將退出，代碼為?0（Job Succeeded）。
如果作業(yè)超時(shí)或被取消，則不會(huì)執(zhí)行?after_script?命令。 存在一個(gè)問(wèn)題，即為超時(shí)或取消的作業(yè)添加對(duì)執(zhí)行?after_script?命令的支持。
stage
使用?stage?定義作業(yè)在哪個(gè)?stage?中運(yùn)行。同一個(gè)?stage?中的作業(yè)可以并行執(zhí)行（參見(jiàn)?額外細(xì)節(jié)）。
如果沒(méi)有定義?stage，則作業(yè)默認(rèn)使用?test?階段。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：包含任意數(shù)量階段名稱(chēng)的數(shù)組。 階段名稱(chēng)可以是：
- 默認(rèn)階段。
- 用戶定義的階段。
stage?示例：
stages:
- build
- test
- deploy
job1:
stage: build
script:
- echo "This job compiles code."
job2:
stage: test
script:
- echo "This job tests the compiled code. It runs when the build stage completes."
job3:
script:
- echo "This job also runs in the test stage".
job4:
stage: deploy
script:
- echo "This job deploys the code. It runs when the test stage completes."額外細(xì)節(jié)：
- 如果作業(yè)在不同的 runner 上運(yùn)行，則它們可以并行運(yùn)行。
- 如果您只有一個(gè) runner，如果 runner 的?
concurrent?設(shè)置大于?1，作業(yè)可以并行運(yùn)行。
stage: .pre
使用?.pre?階段在流水線開(kāi)始時(shí)運(yùn)行作業(yè)。.pre?始終是流水線的第一階段。用戶定義的階段在?.pre?之后執(zhí)行。 您不必在?stages?中定義?.pre。
如果流水線僅包含?.pre?或?.post?階段的作業(yè)，則它不會(huì)運(yùn)行。 在不同的階段必須至少有一項(xiàng)其他作業(yè)。
關(guān)鍵字類(lèi)型：您只能將它與作業(yè)的?stage?關(guān)鍵字一起使用。
stage: .pre?示例：
stages:
- build
- test
job1:
stage: build
script:
- echo "This job runs in the build stage."
first-job:
stage: .pre
script:
- echo "This job runs in the .pre stage, before all other stages."
job2:
stage: test
script:
- echo "This job runs in the test stage."stage: .post
使用?.post?階段使作業(yè)在流水線的末尾運(yùn)行。.post?始終是流水線的最后階段。用戶定義的階段在?.post?之前執(zhí)行。 你不必在?stages?中定義?.post。
如果流水線僅包含?.pre?或?.post?階段的作業(yè)，則它不會(huì)運(yùn)行。 在不同的階段必須至少有一項(xiàng)其他作業(yè)。
關(guān)鍵字類(lèi)型：您只能將它與作業(yè)的?stage?關(guān)鍵字一起使用。
stage: .post?示例：
stages:
- build
- test
job1:
stage: build
script:
- echo "This job runs in the build stage."
last-job:
stage: .post
script:
- echo "This job runs in the .post stage, after all other stages."
job2:
stage: test
script:
- echo "This job runs in the test stage."extends
使用?extends?來(lái)重用配置 section。它是?YAML 錨點(diǎn)?的替代方案，并且更加靈活和可讀。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 流水線中另一個(gè)作業(yè)的名稱(chēng)。
- 流水線中其他作業(yè)的名稱(chēng)列表（數(shù)組）。
extends?示例：
.tests:
script: rake test
stage: test
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
only:
variables:
- $RSPEC在此示例中，rspec?作業(yè)使用來(lái)自.tests?模板作業(yè)的配置。 創(chuàng)建流水線時(shí)：
- 根據(jù)鍵執(zhí)行反向深度合并。
- 將?
.tests?內(nèi)容與?rspec?作業(yè)合并。 - 不合并鍵的值。
結(jié)果是這個(gè)?rspec?作業(yè)：
rspec:
script: rake rspec
stage: test
only:
refs:
- branches
variables:
- $RSPEC額外示例：
- 在 12.0 及更高版本中，您可以為?
extends?使用多個(gè)父項(xiàng)。 -
extends?關(guān)鍵字最多支持 11 級(jí)繼承，但應(yīng)避免使用超過(guò) 3 級(jí)。 - 在上面的例子中，
.tests?是一個(gè)隱藏作業(yè)，但也可以從常規(guī)作業(yè)擴(kuò)展配置。
rules
使用?rules?來(lái)包含或排除流水線中的作業(yè)。
創(chuàng)建流水線時(shí)會(huì)評(píng)估規(guī)則，并按順序評(píng)估，直到第一次匹配。找到匹配項(xiàng)后，該作業(yè)將包含在流水線中或從流水線中排除，具體取決于配置。
您不能在規(guī)則中使用作業(yè)腳本中創(chuàng)建的 dotenv 變量，因?yàn)樵谌魏巫鳂I(yè)運(yùn)行之前都會(huì)評(píng)估規(guī)則。
rules?替換了?only/except，并且它們不能在同一個(gè)作業(yè)中一起使用。如果您將一個(gè)作業(yè)配置為使用兩個(gè)關(guān)鍵字，則系統(tǒng)會(huì)返回一個(gè)?key may not used with rules?錯(cuò)誤。
rules?接受以下規(guī)則：
ifchangesexistsallow_failurevariableswhen
您可以為復(fù)雜規(guī)則，將多個(gè)關(guān)鍵字組合在一起。
作業(yè)被添加到流水線中：
- 如果?
if、changes?或?exists?規(guī)則匹配并且還具有?when: on_success（默認(rèn)）、when: delay?或?when: always。 - 如果達(dá)到的規(guī)則只有?
when: on_success、when: delay?或?when: always。
作業(yè)未添加到流水線中：
- 如果沒(méi)有規(guī)則匹配。
- 如果規(guī)則匹配并且有?
when: never。
您可以在不同的工作中使用?!reference?標(biāo)簽?來(lái)重用?rules?配置。
rules:if
使用?rules:if?子句指定何時(shí)向流水線添加作業(yè)：
- 如果?
if?語(yǔ)句為 true，則將作業(yè)添加到管流水線中。 - 如果?
if?語(yǔ)句為 true，但它與?when: never?結(jié)合使用，則不要將作業(yè)添加到流水線中。 - 如果沒(méi)有?
if?語(yǔ)句為 true，則不要將作業(yè)添加到流水線中。
if:?子句根據(jù)預(yù)定義 CI/CD 變量或自定義 CI/CD 變量。
關(guān)鍵字類(lèi)型：特定于作業(yè)和特定于流水線。您可以將其用作作業(yè)的一部分來(lái)配置作業(yè)行為，或者使用?workflow?來(lái)配置流水線行為。
可能的輸入：CI/CD 變量表達(dá)式。
rules:if?示例：
job:
script: echo "Hello, Rules!"
rules:
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != $CI_DEFAULT_BRANCH
when: never
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
when: manual
allow_failure: true
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME額外細(xì)節(jié)：
- 如果規(guī)則匹配并且沒(méi)有定義?
when，則規(guī)則使用為作業(yè)定義的?when，如果未定義，則默認(rèn)為?on_success。 - 在 14.5 及更早版本中，您可以為每個(gè)規(guī)則定義一次?
when，或者在適用于所有規(guī)則的作業(yè)級(jí)別定義一次。 您不能將作業(yè)級(jí)別的?when?與規(guī)則中的?when?混用。 - 在 14.6 及更高版本中，您可以將作業(yè)級(jí)別的?
when?與規(guī)則中的?when?混合使用。rules?中的?when?配置優(yōu)先于在作業(yè)級(jí)別的?when。 - 與?
script?部分中的變量不同，規(guī)則表達(dá)式中的變量始終格式為?$VARIABLE。- 您可以使用?
rules:if?和?include?來(lái)有條件地包含其他配置文件。
- 您可以使用?
- 在 15.0 及更高版本中，
=~?和?!~?表達(dá)式右側(cè)的變量被認(rèn)為是正則表達(dá)式。
rules:changes
使用?rules:changes?通過(guò)檢查對(duì)特定文件的更改來(lái)指定何時(shí)將作業(yè)添加到流水線。
WARNING: 您應(yīng)該僅將?rules: changes?用于?分支流水線?或?合并請(qǐng)求流水線。 您可以將?rules:changes?與其他管道類(lèi)型一起使用，但是當(dāng)沒(méi)有 Git?push?事件時(shí)，rules:changes?總是評(píng)估為 true。 標(biāo)記流水線、計(jì)劃流水線和手動(dòng)流水線等沒(méi)有與它們關(guān)聯(lián)的 Git?push?事件。 如果沒(méi)有將作業(yè)限制為分支或合并請(qǐng)求管道的?if:，則?rules: changes?作業(yè)總是?添加到這些管道中。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入： 文件路徑數(shù)組。在 13.6 及更高版本中，。
rules:changes?示例：
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes:
- Dockerfile
when: manual
allow_failure: true- 如果流水線是合并請(qǐng)求流水線，請(qǐng)檢查?
Dockerfile?是否有更改。 - 如果?
Dockerfile?已更改，則將作業(yè)作為手動(dòng)作業(yè)添加到流水線中，即使作業(yè)未觸發(fā)，流水線也會(huì)繼續(xù)運(yùn)行（allow_failure: true）。 - 如果?
Dockerfile?沒(méi)有改變，不要將作業(yè)添加到任何流水線（與?when: never?相同）。
額外細(xì)節(jié)：
-
rules: changes?的工作方式與?only: changes?和?except: changes?相同。 - 您可以使用?
when: never?來(lái)實(shí)現(xiàn)類(lèi)似于?except:changes?的規(guī)則。 - 如果任何匹配的文件發(fā)生更改（
OR?操作），changes?將解析為?true。
rules:exists
當(dāng)倉(cāng)庫(kù)中存在某些文件時(shí)，使用?exists?來(lái)運(yùn)行作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：文件路徑數(shù)組。路徑相對(duì)于項(xiàng)目目錄 ($CI_PROJECT_DIR)，不能直接鏈接到項(xiàng)目目錄之外。文件路徑可以使用 glob 模式。
rules:exists?示例：
job:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- exists:
- Dockerfilejob?runs if a?Dockerfile?exists anywhere in the repository.
額外細(xì)節(jié)：
- Glob 模式使用 Ruby?File.fnmatch?和標(biāo)志?
File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB。 - 出于性能原因，系統(tǒng)最多匹配 10,000 個(gè)?
exists?pattern 或文件路徑。在第 10,000 次檢查之后，有 patterned globs的規(guī)則始終匹配。也就是說(shuō)，exists?規(guī)則總是假設(shè)在超過(guò) 10,000 個(gè)文件的項(xiàng)目中匹配。 - 如果找到任何列出的文件，
exists?解析為?true（OR?操作）。
rules:allow_failure
在?rules:?中使用?allow_failure: true?允許作業(yè)在不停止流水線的情況下失敗。
您還可以在手動(dòng)作業(yè)中使用?allow_failure: true。流水線繼續(xù)運(yùn)行，無(wú)需等待手動(dòng)作業(yè)的結(jié)果。allow_failure: false?與規(guī)則中的?when: manual?結(jié)合導(dǎo)致流水線在繼續(xù)之前等待手動(dòng)作業(yè)運(yùn)行。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：true?或?false。如果未定義，則默認(rèn)為?false。
rules:allow_failure?示例：
job:
script: echo "Hello, Rules!"
rules:
- if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
when: manual
allow_failure: true如果規(guī)則匹配，則該作業(yè)是帶有?allow_failure: true?的手動(dòng)作業(yè)。
額外細(xì)節(jié)：
- 規(guī)則級(jí)別?
rules:allow_failure?覆蓋作業(yè)級(jí)別?allow_failure，并且僅在特定規(guī)則觸發(fā)作業(yè)時(shí)適用。
rules:variables
- 引入于 13.7 版本。
- 功能標(biāo)志移除于 13.10 版本。
在?rules:?中使用?variables?來(lái)定義特定條件的變量。
關(guān)鍵字類(lèi)型：特定于作業(yè)。您只能將其用作作業(yè)的一部分。
可能的輸入：格式為?VARIABLE-NAME: value?的變量哈希。
rules:variables?示例：
job:
variables:
DEPLOY_VARIABLE: "default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # Override DEPLOY_VARIABLE defined
DEPLOY_VARIABLE: "deploy-production" # at the job level.
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # Define a new variable.
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"only?/?except
NOTE:?only?和?except?沒(méi)有被積極開(kāi)發(fā)。rules?是控制何時(shí)向流水線添加作業(yè)的首選關(guān)鍵字。
您可以使用?only?和?except?來(lái)控制何時(shí)向流水線添加作業(yè)。
- 使用?
only?來(lái)定義作業(yè)何時(shí)運(yùn)行。 - 使用?
except?定義作業(yè) ** 不** 運(yùn)行的時(shí)間。
only:refs?/?except:refs
使用?only:refs?和?except:refs?關(guān)鍵字來(lái)控制何時(shí)根據(jù)分支名稱(chēng)或流水線類(lèi)型將作業(yè)添加到流水線中。
only:refs?和?except:refs?沒(méi)有被積極開(kāi)發(fā)。rules:if?是使用 refs、正則表達(dá)式或變量來(lái)控制何時(shí)將作業(yè)添加到流水線時(shí)的首選關(guān)鍵字。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：一個(gè)包含任意數(shù)量的數(shù)組：
-
分支名稱(chēng)，例如?
main?或?my-feature-branch。 - 正則表達(dá)式匹配分支名稱(chēng)，例如 `/^feature-.*/`。
-
以下關(guān)鍵詞：
值 描述 api對(duì)于由 pipelines API 觸發(fā)的流水線。 branches當(dāng)流水線的 Git 引用是一個(gè)分支時(shí)。 chat對(duì)于使用 GitLab ChatOps 命令創(chuàng)建的流水線。 external當(dāng)您使用極狐GitLab 以外的 CI 服務(wù)時(shí)。 external_pull_requests在 GitHub 上創(chuàng)建或更新外部拉取請(qǐng)求時(shí)。 merge_requests對(duì)于在創(chuàng)建或更新合并請(qǐng)求時(shí)創(chuàng)建的流水線。啟用合并請(qǐng)求流水線、合并結(jié)果流水線和合并隊(duì)列。 pipelines對(duì)于通過(guò)使用帶有? CI_JOB_TOKEN?的 API 創(chuàng)建的多項(xiàng)目流水線或?trigger?關(guān)鍵字。pushes對(duì)于由? git push?事件觸發(fā)的流水線，包括分支和標(biāo)簽。schedules對(duì)于計(jì)劃流水線。 tags當(dāng)流水線的 Git 引用是標(biāo)簽時(shí)。 triggers對(duì)于使用觸發(fā)器令牌創(chuàng)建的流水線。 web對(duì)于通過(guò)在 GitLab UI 中，從項(xiàng)目的?CI/CD > 流水線?部分選擇?運(yùn)行流水線?創(chuàng)建的流水線。
only:refs?和?except:refs?示例：
job1:
script: echo
only:
- main
- /^issue-.*$/
- merge_requests
job2:
script: echo
except:
- main
- /^stable-branch.*$/
- schedules額外細(xì)節(jié)：
-
預(yù)定流水線在特定分支上運(yùn)行，因此配置了?
only: branch?的作業(yè)也可以在預(yù)定流水線上運(yùn)行。添加?except: schedules?以防止帶有?only: branch?的作業(yè)在預(yù)定流水線上運(yùn)行。 -
only?或?except?不使用任何其他關(guān)鍵字等價(jià)于?only: refs?或?except: refs。例如，以下兩個(gè)作業(yè)配置具有相同的行為：job1: script: echo only: - branches job2: script: echo only: refs: - branches -
如果作業(yè)不使用?
only、except?或?rules，則?only?默認(rèn)設(shè)置為?branches?和?tags。例如，
job1?和?job2?是等價(jià)的：job1: script: echo "test" job2: script: echo "test" only: - branches - tags
only:variables?/?except:variables
根據(jù) CI/CD 變量 的狀態(tài)，使用?only:variables?或?except:variables?關(guān)鍵字來(lái)控制何時(shí)將作業(yè)添加到流水線中。
only:variables?和?except:variables?沒(méi)有被積極開(kāi)發(fā)。rules:if?是使用 refs、正則表達(dá)式或變量來(lái)控制何時(shí)將作業(yè)添加到流水線時(shí)的首選關(guān)鍵字。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：CI/CD 變量表達(dá)式的數(shù)組。
only:variables?示例：
deploy:
script: cap staging deploy
only:
variables:
- $RELEASE == "staging"
- $STAGINGonly:changes?/?except:changes
當(dāng) Git 推送事件修改文件時(shí)，使用?changes?關(guān)鍵字和?only?來(lái)運(yùn)行作業(yè)，或使用?except?來(lái)跳過(guò)作業(yè)。
在具有以下引用的流水線中使用?changes：
branchesexternal_pull_requestsmerge_requests
only:changes?和?except:changes?沒(méi)有被積極開(kāi)發(fā)。rules:if?是使用 refs、正則表達(dá)式或變量來(lái)控制何時(shí)將作業(yè)添加到流水線時(shí)的首選關(guān)鍵字。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：一個(gè)包含任意數(shù)量的數(shù)組：
- 文件路徑。
- 單個(gè)目錄的通配符路徑，例如?
path/to/directory/*，或一個(gè)目錄及其所有子目錄，例如?path/to/directory/**/*。 - 具有相同擴(kuò)展名或多個(gè)擴(kuò)展名的所有文件的通配符 (glob) 路徑，例如?
*.md?或?path/to/directory/*.{rb,py,sh}。請(qǐng)參閱?Ruby?fnmatch?文檔?或支持的語(yǔ)法列表。 - 根目錄或所有目錄中文件的通配符路徑，用雙引號(hào)括起來(lái)。例如
"*.json"?或"**/*.json"。
only:changes?示例：
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
only:
refs:
- branches
changes:
- Dockerfile
- docker/scripts/*
- dockerfiles/**/*
- more_scripts/*.{rb,py,sh}
- "**/*.json"額外細(xì)節(jié)：
- 如果任何匹配的文件發(fā)生更改（
OR?操作），changes?將解析為?true。 - 如果使用除?
branches、external_pull_requests?或?merge_requests?以外的引用，changes?無(wú)法確定給定文件是新文件還是舊文件，并且總是返回?true。 - 如果您將?
only: changes?與其他引用一起使用，作業(yè)將忽略更改并始終運(yùn)行。 - 如果您將?
except: changes?與其他引用一起使用，作業(yè)將忽略更改并且永遠(yuǎn)不會(huì)運(yùn)行。
only:kubernetes?/?except:kubernetes
使用?only:kubernetes?或?except:kubernetes?來(lái)控制當(dāng) Kubernetes 服務(wù)在項(xiàng)目中處于活動(dòng)狀態(tài)時(shí)是否將作業(yè)添加到流水線中。
關(guān)鍵字類(lèi)型：特定于作業(yè)。您只能將其用作作業(yè)的一部分。
可能的輸入：kubernetes?策略只接受?active?關(guān)鍵字。
only:kubernetes?示例：
deploy:
only:
kubernetes: active在此示例中，deploy?作業(yè)僅在項(xiàng)目中的 Kubernetes 服務(wù)處于活動(dòng)狀態(tài)時(shí)運(yùn)行。
needs
- 引入于 12.2 版本。
- 于 12.3 版本，
needs?數(shù)組中的最大作業(yè)數(shù)從 5 增加到 50。- 于 12.8 版本，
needs: []?讓作業(yè)立即開(kāi)始。- 于 14.2 版本，您可以參考與您正在配置的作業(yè)處于同一階段的作業(yè)。
使用?needs:?來(lái)不按順序執(zhí)行作業(yè)。使用?needs?的作業(yè)之間的關(guān)系可以可視化為有向無(wú)環(huán)圖。
您可以忽略階段排序并運(yùn)行一些作業(yè)，而無(wú)需等待其他作業(yè)完成。 多個(gè)階段的作業(yè)可以同時(shí)運(yùn)行。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 一個(gè)數(shù)組的作業(yè)。
- 一個(gè)空數(shù)組 (
[])，用于將作業(yè)設(shè)置為在創(chuàng)建流水線后立即啟動(dòng)。
needs?示例：
linux:build:
stage: build
script: echo "Building linux..."
mac:build:
stage: build
script: echo "Building mac..."
lint:
stage: test
needs: []
script: echo "Linting..."
linux:rspec:
stage: test
needs: ["linux:build"]
script: echo "Running rspec on linux..."
mac:rspec:
stage: test
needs: ["mac:build"]
script: echo "Running rspec on mac..."
production:
stage: deploy
script: echo "Running production..."示例創(chuàng)建四個(gè)執(zhí)行路徑：
- Linter：
lint?作業(yè)立即運(yùn)行，無(wú)需等待?build?階段完成，因?yàn)樗鼪](méi)有需求（needs: []）。 - Linux 路徑：
linux:rspec?和?linux:rubocop?作業(yè)在?linux:build?作業(yè)完成后立即運(yùn)行，無(wú)需等待?mac:build?完成。 - macOS 路徑：
mac:rspec?和?mac:rubocop?作業(yè)在?mac:build?作業(yè)完成后立即運(yùn)行，無(wú)需等待?linux:build?完成。 -
production?作業(yè)在所有先前的作業(yè)完成后立即運(yùn)行；在這種情況下：linux:build、linux:rspec、linux:rubocop、mac:build、mac:rspec、mac:rubocop。
額外細(xì)節(jié)：
-
needs:?數(shù)組中單個(gè)作業(yè)可以需要的最大作業(yè)數(shù)是有限的：- 對(duì)于自助管理實(shí)例，默認(rèn)限制為 50。此限制可以更改。
- 如果?
needs:?指的是使用?parallel?關(guān)鍵字的作業(yè)，它取決于并行創(chuàng)建的所有作業(yè)，而不僅僅是一個(gè)作業(yè)。 默認(rèn)情況下，它還從所有并行作業(yè)下載產(chǎn)物。如果產(chǎn)物具有相同的名稱(chēng)，它們會(huì)相互覆蓋，并且只保存最后下載的產(chǎn)物。 - 在 14.1 及更高版本中，您可以引用與您正在配置的作業(yè)處于同一階段的作業(yè)。在自助管理的 14.2 及更高版本上，此功能默認(rèn)可用。
- 在 14.0 及更早版本中，您只能引用早期階段的作業(yè)。必須為所有使用?
needs:?關(guān)鍵字或在作業(yè)的?needs:?部分中引用的作業(yè)明確定義階段。 - 在 13.9 及更早版本中，如果?
needs:?指的是由于?only、except?或?rules?可能無(wú)法添加到流水線中的作業(yè)，則流水線可能無(wú)法創(chuàng)建。
needs:artifacts
當(dāng)作業(yè)使用?needs?時(shí)，默認(rèn)情況下它不再下載前一階段的所有產(chǎn)物，因?yàn)閹в?needs?的作業(yè)可以在早期階段完成之前開(kāi)始。使用?needs，您只能從?needs:?配置中列出的作業(yè)中下載產(chǎn)物。
使用?artifacts: true（默認(rèn)）或?artifacts: false?來(lái)控制何時(shí)在使用?needs?的作業(yè)中下載產(chǎn)物。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。 Must be used with?needs:job.
可能的輸入：
-
true（默認(rèn)）或?false.
needs:artifacts?示例：
test-job1:
stage: test
needs:
- job: build_job1
artifacts: true
test-job2:
stage: test
needs:
- job: build_job2
artifacts: false
test-job3:
needs:
- job: build_job1
artifacts: true
- job: build_job2
- build_job3在這個(gè)例子中：
-
test-job1?作業(yè)下載?build_job1?產(chǎn)物 -
test-job2?作業(yè)不會(huì)下載?build_job2?產(chǎn)物。 -
test-job3?作業(yè)從所有三個(gè)?build_jobs?下載產(chǎn)物，因?yàn)閷?duì)于所有三個(gè)需要的作業(yè)，artifacts:?是?true，或默認(rèn)為?true。
額外細(xì)節(jié)：
- 在 12.6 及更高版本中，您不能將?dependencies?關(guān)鍵字與?
needs?結(jié)合使用。
needs:project?(PREMIUM)
使用?needs:project?從其他流水線中最多五個(gè)作業(yè)下載產(chǎn)物。 從指定引用的最新成功流水線下載產(chǎn)物。 要指定多個(gè)作業(yè)，請(qǐng)將每個(gè)作業(yè)添加為?needs?關(guān)鍵字下的單獨(dú)數(shù)組項(xiàng)。
如果為指定的 ref 運(yùn)行流水線，則帶有?needs:project?的作業(yè)不會(huì)等待流水線完成。相反，該作業(yè)從成功完成的最新流水線下載產(chǎn)物。
needs:project?必須與?job:、ref:?和?artifacts:?一起使用。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
-
needs:project：完整的項(xiàng)目路徑，包括命名空間和群組。 -
job：從中下載產(chǎn)物的作業(yè)。 -
ref：從中下載產(chǎn)物的引用。 -
artifacts：必須為?true?才能下載產(chǎn)物。
needs:project?示例：
build_job:
stage: build
script:
- ls -lhR
needs:
- project: namespace/group/project-name
job: build-1
ref: main
artifacts: true
- project: namespace/group/project-name-2
job: build-2
ref: main
artifacts: true在此示例中，build_job?從?group/project-name?和?group/project-name-2?項(xiàng)目中的?main?分支上最新成功的?build-1?和?build-2?作業(yè)下載產(chǎn)物。
在 13.3 及更高版本中，您可以在?needs:project?中使用 CI/CD 變量，例如：
build_job:
stage: build
script:
- ls -lhR
needs:
- project: $CI_PROJECT_PATH
job: $DEPENDENCY_JOB_NAME
ref: $ARTIFACTS_DOWNLOAD_REF
artifacts: true額外細(xì)節(jié)：
- 要從當(dāng)前項(xiàng)目中的不同流水線下載產(chǎn)物，請(qǐng)將?
project:?設(shè)置為與當(dāng)前項(xiàng)目相同，但使用與當(dāng)前流水線不同的引用。在同一個(gè) ref 上運(yùn)行的并發(fā)流水線可能會(huì)覆蓋產(chǎn)物。 - 運(yùn)行流水線的用戶必須至少具有組或項(xiàng)目的報(bào)告者角色，或者群組/項(xiàng)目必須具有公開(kāi)可見(jiàn)性。
- 你不能在與?trigger?相同的作業(yè)中使用?
needs:project。 - 當(dāng)使用?
needs:project?從另一個(gè)流水線下載產(chǎn)物時(shí)，作業(yè)不會(huì)等待所需的作業(yè)完成。有向無(wú)環(huán)圖僅限于同一流水線中的作業(yè)。確保其他流水線中所需的作業(yè)在需要它的作業(yè)嘗試下載產(chǎn)物之前完成。 - 您無(wú)法從在?parallel:?中運(yùn)行的作業(yè)下載產(chǎn)物。
- 13.3 中引入了對(duì)?
project、job?和?ref?中的 CI/CD 變量的支持。 13.4 中刪除了功能標(biāo)志。
needs:pipeline:job
引入于 13.7 版本。
子流水線?可以從其父流水線或同一父子流水線層次結(jié)構(gòu)中的另一個(gè)子流水線中的作業(yè)下載產(chǎn)物。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
-
needs:pipeline：流水線 ID。必須是存在于同一父子流水線層次結(jié)構(gòu)中的流水線。 -
job:：從中下載產(chǎn)物的作業(yè)。
needs:pipeline:job?示例：
-
父流水線 (
.gitlab-ci.yml)：create-artifact: stage: build script: echo 'sample artifact' > artifact.txt artifacts: paths: [artifact.txt] child-pipeline: stage: test trigger: include: child.yml strategy: depend variables: PARENT_PIPELINE_ID: $CI_PIPELINE_ID -
子流水線 (
child.yml)：use-artifact: script: cat artifact.txt needs: - pipeline: $PARENT_PIPELINE_ID job: create-artifact
在此示例中，父流水線中的?create-artifact?作業(yè)創(chuàng)建了一些產(chǎn)物。child-pipeline?作業(yè)觸發(fā)子流水線，并將?CI_PIPELINE_ID?變量作為新的?PARENT_PIPELINE_ID?變量傳遞給子流水線。子流水線可以使用?needs:pipeline?中的變量從父流水線下載產(chǎn)物。
額外細(xì)節(jié)：
-
pipeline?屬性不接受當(dāng)前的流水線 ID ($CI_PIPELINE_ID)。要從當(dāng)前流水線中的作業(yè)下載產(chǎn)物，請(qǐng)使用?needs。
needs:optional
- 引入于 13.10 版本。
- 功能標(biāo)志移除于 14.0 版本。
如果需要有時(shí)在流水線中不存在的作業(yè)，請(qǐng)將?optional: true?添加到?needs?配置中。如果未定義，optional: false?是默認(rèn)值。
使用?rules、only?或?except?的作業(yè)可能并不總是添加到流水線中。系統(tǒng)在啟動(dòng)流水線之前檢查?needs?關(guān)系：
- 如果需求條目具有?
optional: true?并且所需的作業(yè)存在于流水線中，則作業(yè)會(huì)在開(kāi)始之前等待它完成。 - 如果所需的作業(yè)不存在，則可以在滿足所有其他 needs 要求時(shí)開(kāi)始該作業(yè)。
- 如果?
needs?部分僅包含可選作業(yè)，并且沒(méi)有添加到流水線中，則作業(yè)會(huì)立即啟動(dòng)（與空的?needs?條目相同：needs: []）。 - 如果需要的作業(yè)有?
optional: false，但未添加到流水線，則流水線無(wú)法啟動(dòng)，并出現(xiàn)類(lèi)似以下錯(cuò)誤：'job1' job needs 'job2' job, but it was not added to the pipeline。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
needs:optional?示例：
build-job:
stage: build
test-job1:
stage: test
test-job2:
stage: test
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy-job:
stage: deploy
needs:
- job: test-job2
optional: true
- job: test-job1
review-job:
stage: deploy
needs:
- job: test-job2
optional: true在這個(gè)例子中：
-
build-job、test-job1?和?test-job2?按階段順序開(kāi)始。 - 當(dāng)分支是默認(rèn)分支時(shí)，
test-job2?被添加到流水線中，所以：-
deploy-job?等待?test-job1?和?test-job2?完成。 -
review-job?等待?test-job2?完成。
-
- 當(dāng)分支不是默認(rèn)分支時(shí)，
test-job2?不會(huì)添加到流水線中，所以：-
deploy-job?只等待?test-job1?完成，而不等待錯(cuò)過(guò)的?test-job2。 -
review-job?沒(méi)有其他需要的作業(yè)并立即啟動(dòng)（與?build-job?同時(shí)），如?needs: []。
-
needs:pipeline
您可以使用?needs:pipeline?關(guān)鍵字將流水線狀態(tài)從上游流水線鏡像到橋接作業(yè)。來(lái)自默認(rèn)分支的最新流水線狀態(tài)被復(fù)制到橋接作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 完整的項(xiàng)目路徑，包括命名空間和群組。如果項(xiàng)目在同一個(gè)組或命名空間中，你可以從?
project:?關(guān)鍵字中省略它們。例如：project: group/project-name?或?project: project-name。
needs:pipeline?示例：
upstream_bridge:
stage: test
needs:
pipeline: other/project額外細(xì)節(jié)：
- 如果您將?
job?關(guān)鍵字添加到?needs:pipeline，該作業(yè)將不再反映流水線狀態(tài)。更改為?needs:pipeline:job。
tags
- 于 14.3 版本，在自助管理版上啟用的每個(gè)作業(yè)限制為 50 個(gè)標(biāo)簽。
使用?tags?從項(xiàng)目可用的所有 runner 列表中選擇一個(gè)特定的 runner。
注冊(cè) runner 時(shí)，您可以指定 runner 的標(biāo)簽，例如?ruby、postgres?或?development。要獲取并運(yùn)行作業(yè)，必須為 runner 分配作業(yè)中列出的每個(gè)標(biāo)簽。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：
- 標(biāo)簽名稱(chēng)數(shù)組。
- 14.1 及更高版本中的 CI/CD 變量。
tags?示例：
job:
tags:
- ruby
- postgres在此示例中，只有同時(shí)具有?ruby?和?postgres?標(biāo)簽的 runner 才能運(yùn)行該作業(yè)。
額外細(xì)節(jié)：
- 在 14.3 及更高版本中，標(biāo)簽數(shù)量必須小于?
50。
allow_failure
使用?allow_failure?來(lái)確定當(dāng)作業(yè)失敗時(shí)，流水線是否應(yīng)該繼續(xù)運(yùn)行。
- 要讓流水線繼續(xù)運(yùn)行后續(xù)作業(yè)，請(qǐng)使用?
allow_failure: true。 - 要停止流水線運(yùn)行后續(xù)作業(yè)，請(qǐng)使用?
allow_failure: false。
當(dāng)允許作業(yè)失敗 (allow_failure: true) 時(shí)，橙色警告 ({status_warning}) 表示作業(yè)失敗。但是，流水線是成功的，并且關(guān)聯(lián)的提交被標(biāo)記為已通過(guò)且沒(méi)有警告。
在以下情況下會(huì)顯示相同的警告：
- 階段中的所有其他工作均成功。
- 流水線中的所有其他作業(yè)均成功。
allow_failure?的默認(rèn)值為：
- 手動(dòng)作業(yè)為 `true`。
- 對(duì)于在?rules?中使用?
when:manual?的作業(yè)為?false。 - 在所有其它情況下為?
false。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：true?或?false。
allow_failure?示例：
job1:
stage: test
script:
- execute_script_1
job2:
stage: test
script:
- execute_script_2
allow_failure: true
job3:
stage: deploy
script:
- deploy_to_staging在這個(gè)例子中，job1?和?job2?并行運(yùn)行：
- 如果?
job1?失敗，deploy?階段的作業(yè)不會(huì)啟動(dòng)。 - 如果?
job2?失敗，deploy?階段的作業(yè)仍然可以啟動(dòng)。
額外細(xì)節(jié)：
- 您可以使用?
allow_failure?作為?rules:?的子鍵。 - 您可以在手動(dòng)作業(yè)中使用?
allow_failure: false?來(lái)創(chuàng)建阻塞的手動(dòng)作業(yè)。在手動(dòng)作業(yè)啟動(dòng)并成功完成之前，阻塞的流水線不會(huì)在后續(xù)階段運(yùn)行任何作業(yè)。
allow_failure:exit_codes
- 引入于 13.8 版本。
- 功能標(biāo)志移除于 13.9 版本。
使用?allow_failure:exit_codes?來(lái)控制何時(shí)允許作業(yè)失敗。對(duì)于任何列出的退出代碼，作業(yè)是?allow_failure: true，對(duì)于任何其他退出代碼，allow_failure?為 false。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 單個(gè)退出代碼。
- 退出代碼數(shù)組。
allow_failure?示例：
test_job_1:
script:
- echo "Run a script that results in exit code 1. This job fails."
- exit 1
allow_failure:
exit_codes: 137
test_job_2:
script:
- echo "Run a script that results in exit code 137. This job is allowed to fail."
- exit 137
allow_failure:
exit_codes:
- 137
- 255when
使用?when?配置作業(yè)運(yùn)行的條件。如果未在作業(yè)中定義，則默認(rèn)值為?when: on_success。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您可以將其用作作業(yè)的一部分。when: always?和?when: never?也可以在?workflow:rules?中使用。
可能的輸入：
-
on_success（默認(rèn)）：僅當(dāng)早期階段的所有作業(yè)都成功或具有?allow_failure: true?時(shí)才運(yùn)行作業(yè)。 -
manual：僅在手動(dòng)觸發(fā)時(shí)運(yùn)行作業(yè)。 -
always：無(wú)論早期階段的作業(yè)狀態(tài)如何，都運(yùn)行作業(yè)。也可以在?workflow:rules?中使用。 -
on_failure：只有在早期階段至少有一個(gè)作業(yè)失敗時(shí)才運(yùn)行作業(yè)。 -
delayed：作業(yè)的執(zhí)行延遲指定的持續(xù)時(shí)間。 -
never：不要運(yùn)行作業(yè)。只能在?rules?部分或?workflow: rules?中使用。
when?示例：
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在這個(gè)例子中，腳本：
- 只有當(dāng)?
build_job?失敗時(shí)才執(zhí)行?cleanup_build_job。 - 無(wú)論成功或失敗，始終將?
cleanup_job?作為流水線的最后一步執(zhí)行。 - 在 GitLab UI 中手動(dòng)運(yùn)行時(shí)執(zhí)行?
deploy_job。
額外細(xì)節(jié)：
- 在 13.5 及更高版本中，您可以在與?trigger?相同的作業(yè)中使用?
when:manual。在 13.4 及更早版本中，將它們一起使用會(huì)導(dǎo)致錯(cuò)誤?jobs:#{job-name} when should be on_success, on_failure or always。 -
allow_failure?的默認(rèn)行為通過(guò)?when: manual?更改為?true。但是，如果您將?when: manual?與?rules?一起使用，allow_failure?默認(rèn)為?false。
environment
使用?environment?定義作業(yè)部署到的環(huán)境。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：作業(yè)部署到的環(huán)境的名稱(chēng)，采用以下格式之一：
- 純文本，包括字母、數(shù)字、空格和以下字符：
-、_、/、$、{、}。 - CI/CD 變量，包括在
.gitlab-ci.yml?文件中定義的預(yù)定義、安全或變量。您不能使用在?script?部分中定義的變量。
environment?示例：
deploy to production:
stage: deploy
script: git push production HEAD:main
environment: production額外細(xì)節(jié)：
- 如果您指定了一個(gè)?
environment?并且不存在具有該名稱(chēng)的環(huán)境，則會(huì)創(chuàng)建一個(gè)環(huán)境。
environment:name
為環(huán)境設(shè)置名稱(chēng)。
常見(jiàn)的環(huán)境名稱(chēng)是?qa、staging?和?production，但您可以使用任何名稱(chēng)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：作業(yè)部署到的環(huán)境的名稱(chēng)，采用以下格式之一：
- 純文本，包括字母、數(shù)字、空格和以下字符：
-、_、/、$、{、}。 - CI/CD 變量，包括在?
.gitlab-ci.yml?文件中定義的預(yù)定義、安全或變量。 您不能使用在?script?部分中定義的變量。
environment:name?示例：
deploy to production:
stage: deploy
script: git push production HEAD:main
environment:
name: productionenvironment:url
為環(huán)境設(shè)置 URL。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：?jiǎn)蝹€(gè) URL，采用以下格式之一：
- 純文本，如?
https://prod.example.com。 - CI/CD 變量，包括在?
.gitlab-ci.yml?文件中定義的預(yù)定義、安全或變量。 您不能使用在?script?部分中定義的變量。
environment:url?示例：
deploy to production:
stage: deploy
script: git push production HEAD:main
environment:
name: production
url: https://prod.example.com額外細(xì)節(jié)：
- 作業(yè)完成后，您可以通過(guò)選擇合并請(qǐng)求、環(huán)境或部署頁(yè)面中的按鈕來(lái)訪問(wèn) URL。
environment:on_stop
關(guān)閉（停止）環(huán)境可以通過(guò)在?environment?下定義的?on_stop?關(guān)鍵字來(lái)實(shí)現(xiàn)。 它聲明了一個(gè)為了關(guān)閉環(huán)境而運(yùn)行的不同作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
額外細(xì)節(jié)：
- 有關(guān)更多詳細(xì)信息和示例，請(qǐng)參閱?environment:action。
environment:action
使用?action?關(guān)鍵字來(lái)指定作業(yè)如何與環(huán)境交互。
| 值 | 描述 |
|---|---|
start |
默認(rèn)值。 表示作業(yè)啟動(dòng)環(huán)境。部署是在作業(yè)啟動(dòng)后創(chuàng)建的。 |
prepare |
表示作業(yè)只準(zhǔn)備環(huán)境。它不會(huì)觸發(fā)部署。 |
stop |
表示作業(yè)停止部署。請(qǐng)參閱下面的示例。 |
舉例：
review_app:
stage: deploy
script: make deploy-app
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_ENVIRONMENT_SLUG.example.com
on_stop: stop_review_app
stop_review_app:
stage: deploy
variables:
GIT_STRATEGY: none
script: make delete-app
when: manual
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop在上面的例子中，review_app?作業(yè)部署到?review?環(huán)境。在?on_stop?下列出了一個(gè)新的?stop_review_app?作業(yè)。在?review_app?作業(yè)完成后，它會(huì)根據(jù)?when?下定義的內(nèi)容觸發(fā)?stop_review_app?作業(yè)。在這種情況下，它被設(shè)置為?manual，因此它需要來(lái)自 GitLab UI 的手動(dòng)操作運(yùn)行。
同樣在示例中，GIT_STRATEGY?設(shè)置為?none。如果?stop_review_app?作業(yè)自動(dòng)觸發(fā)，則 runner 在刪除分支后不會(huì)嘗試檢出代碼。
該示例還覆蓋了全局變量。如果您的?stop?environment?作業(yè)依賴于全局變量，請(qǐng)?jiān)谠O(shè)置?GIT_STRATEGY?且在不覆蓋全局變量的情況下，更改作業(yè)時(shí)使用錨點(diǎn)變量。
stop_review_app?作業(yè)需要定義以下關(guān)鍵字：
-
when，定義于：- 作業(yè)級(jí)別。
-
在規(guī)則子句中。如果使用?
rules:?和?when: manual，您還應(yīng)該設(shè)置?allow_failure: true，這樣即使作業(yè)沒(méi)有運(yùn)行，可實(shí)現(xiàn)也可以完成。
environment:nameenvironment:action
此外，兩個(gè)作業(yè)都應(yīng)該具有匹配的?rules?或?only/except?配置。
在上面的示例中，如果配置不相同：
-
stop_review_app?作業(yè)可能不會(huì)包含在包含?review_app?作業(yè)的所有流水線中。 - 無(wú)法觸發(fā)?
action: stop?來(lái)自動(dòng)停止環(huán)境。
environment:auto_stop_in
auto_stop_in?關(guān)鍵字指定環(huán)境的生命周期。當(dāng)環(huán)境過(guò)期時(shí)，系統(tǒng)會(huì)自動(dòng)停止它。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：用自然語(yǔ)言編寫(xiě)的一段時(shí)間。 例如，這些都是等價(jià)的：
168 hours7 daysone week
environment:auto_stop_in?示例：
review_app:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_SLUG
auto_stop_in: 1 day當(dāng)為?review_app?創(chuàng)建環(huán)境時(shí)，環(huán)境的生命周期設(shè)置為?1 day。 每次部署 review app 時(shí)，該生命周期也會(huì)重置為?1 day。
environment:kubernetes
使用?kubernetes?關(guān)鍵字將部署配置到與您的項(xiàng)目關(guān)聯(lián)的 Kubernetes 集群。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
environment:kubernetes?示例：
deploy:
stage: deploy
script: make deploy-app
environment:
name: production
kubernetes:
namespace: production此配置使用?production?Kubernetes 命名空間。
額外細(xì)節(jié)：
- 由極狐GitLab 管理 的 Kubernetes 集群不支持 Kubernetes 配置。
environment:deployment_tier
引入于 13.10 版本。
使用?deployment_tier?關(guān)鍵字指定部署環(huán)境的層級(jí)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：以下之一：
productionstagingtestingdevelopmentother
environment:deployment_tier?示例：
deploy:
script: echo
environment:
name: customer-portal
deployment_tier: production動(dòng)態(tài)環(huán)境
使用 CI/CD 變量動(dòng)態(tài)命名環(huán)境。
例如：
deploy as review app:
stage: deploy
script: make deploy
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_ENVIRONMENT_SLUG.example.com/deploy as review app?作業(yè)被標(biāo)記為動(dòng)態(tài)創(chuàng)建?review/$CI_COMMIT_REF_SLUG?環(huán)境的部署。$CI_COMMIT_REF_SLUG?是由 runner 設(shè)置的?CI/CD 變量。$CI_ENVIRONMENT_SLUG?變量基于環(huán)境名稱(chēng)，但適合包含在 URL 中。如果?deploy as review app?作業(yè)在名為?pow?的分支中運(yùn)行，則可以使用類(lèi)似?https://review-pow.example.com/?的 URL 訪問(wèn)該環(huán)境。
常見(jiàn)的用例是為分支機(jī)構(gòu)創(chuàng)建動(dòng)態(tài)環(huán)境并將它們用作審核應(yīng)用程序。
cache
使用?cache?指定要在作業(yè)之間緩存的文件和目錄列表。您只能使用本地工作副本中的路徑。
緩存在流水線和作業(yè)之間共享。緩存在產(chǎn)物之前恢復(fù)。
cache:paths
使用?cache:paths?關(guān)鍵字來(lái)選擇要緩存的文件或目錄。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：相對(duì)于項(xiàng)目目錄的路徑數(shù)組（$CI_PROJECT_DIR）。您可以使用使用 glob 模式的通配符：
- 在 GitLab Runner 13.0 及更高版本中，doublestar.Glob。
- 在 GitLab Runner 12.10 及更早版本中，filepath.Match。
cache:paths?示例：
緩存?binaries?中以?.apk?和?.config?文件結(jié)尾的所有文件：
rspec:
script:
- echo "This job uses a cache."
cache:
key: binaries-cache
paths:
- binaries/*.apk
- .configcache:key
使用?cache:key?關(guān)鍵字為每個(gè)緩存提供唯一的標(biāo)識(shí)鍵。使用相同緩存鍵的所有作業(yè)都使用相同的緩存，包括在不同的流水線中。
如果未設(shè)置，則默認(rèn)鍵為?default。所有帶有?cache:?關(guān)鍵字但沒(méi)有?cache:key?的作業(yè)共享?default?緩存。
必須與?cache: path?一起使用，否則不會(huì)緩存任何內(nèi)容。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：
- 一個(gè)字符串。
- 預(yù)定義變量。
- 兩者的結(jié)合。
cache:key?示例：
cache-job:
script:
- echo "This job uses a cache."
cache:
key: binaries-cache-$CI_COMMIT_REF_SLUG
paths:
- binaries/額外細(xì)節(jié)：
-
如果你使用?Windows Batch?運(yùn)行你的 shell 腳本，你需要用?
%?替換?$。 例如：密鑰：%CI_COMMIT_REF_SLUG% -
cache:key?值不能包含：-
/?字符，或等效的 URI 編碼的?%2F。 - 只有?
.?字符（任何數(shù)字），或等效的 URI 編碼的?%2E。
-
-
緩存在作業(yè)之間共享，因此如果您為不同的作業(yè)使用不同的路徑，您還應(yīng)該設(shè)置不同的?
cache:key。 否則緩存內(nèi)容可能會(huì)被覆蓋。
cache:key:files
使用?cache:key:files?關(guān)鍵字在一兩個(gè)特定文件更改時(shí)生成新密鑰。cache:key:files?可讓您重用一些緩存，并減少重建它們的頻率，從而加快后續(xù)流水線運(yùn)行的速度。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：一個(gè)或兩個(gè)文件路徑的數(shù)組。
cache:key:files?示例：
cache-job:
script:
- echo "This job uses a cache."
cache:
key:
files:
- Gemfile.lock
- package.json
paths:
- vendor/ruby
- node_modules此示例為 Ruby 和 Node.js 依賴項(xiàng)創(chuàng)建緩存。緩存綁定到當(dāng)前版本的?Gemfile.lock?和?package.json?文件。當(dāng)這些文件之一發(fā)生變化時(shí)，將計(jì)算一個(gè)新的緩存鍵并創(chuàng)建一個(gè)新的緩存。任何使用相同的?Gemfile.lock?和?package.json?以及?cache:key:files?的未來(lái)作業(yè)都會(huì)使用新的緩存，而不是重建依賴項(xiàng)。
額外信息：緩存?key?是根據(jù)最近更改了每個(gè)列出的文件的提交計(jì)算得出的 SHA。如果在任何提交中都沒(méi)有更改任何文件，則回退鍵是?default。
cache:key:prefix
使用?cache:key:prefix?將前綴與為?cache:key:files?計(jì)算的 SHA 結(jié)合起來(lái)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：
- 一個(gè)字符串
- 預(yù)定義變量
- 兩者的結(jié)合。
cache:key:prefix?示例：
rspec:
script:
- echo "This rspec job uses a cache."
cache:
key:
files:
- Gemfile.lock
prefix: $CI_JOB_NAME
paths:
- vendor/ruby例如，添加?$CI_JOB_NAME?的?prefix?會(huì)使密鑰看起來(lái)像?rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5。 如果分支更改了?Gemfile.lock，則該分支會(huì)為?cache:key:files?提供一個(gè)新的 SHA 校驗(yàn)和。 生成一個(gè)新的緩存鍵，并為該鍵創(chuàng)建一個(gè)新的緩存。如果沒(méi)有找到?Gemfile.lock，前綴會(huì)被添加到?default，因此示例中的鍵是?rspec-default。
額外細(xì)節(jié)：如果在任何提交中都沒(méi)有更改?cache:key:files?中的文件，則會(huì)將前綴添加到?default?鍵。
cache:untracked
使用?untracked: true?來(lái)緩存 Git 倉(cāng)庫(kù)中所有未跟蹤的文件：
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：true?或?false（默認(rèn)）。
cache:untracked?示例：
rspec:
script: test
cache:
untracked: true額外細(xì)節(jié)：
-
您可以將?
cache:untracked?與?cache:paths?結(jié)合使用來(lái)緩存所有未跟蹤的文件以及配置路徑中的文件。例如：rspec: script: test cache: untracked: true paths: - binaries/
cache:when
使用?cache:when?定義何時(shí)根據(jù)作業(yè)的狀態(tài)保存緩存。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：
-
on_success（默認(rèn)）：僅在作業(yè)成功時(shí)保存緩存。 -
on_failure：僅在作業(yè)失敗時(shí)保存緩存。 -
always：始終保存緩存。
cache:when?示例：
rspec:
script: rspec
cache:
paths:
- rspec/
when: 'always'無(wú)論作業(yè)是失敗還是成功，此示例都會(huì)存儲(chǔ)緩存。
cache:policy
要更改緩存的上傳和下載行為，請(qǐng)使用?cache:policy?關(guān)鍵字。 默認(rèn)情況下，作業(yè)在作業(yè)開(kāi)始時(shí)下載緩存，并在作業(yè)結(jié)束時(shí)將更改上傳到緩存。 這是?pull-push?策略（默認(rèn)）。
要將作業(yè)設(shè)置為僅在作業(yè)開(kāi)始時(shí)下載緩存，但在作業(yè)完成時(shí)從不上傳更改，請(qǐng)使用?cache:policy:pull。
要將作業(yè)設(shè)置為僅在作業(yè)完成時(shí)上傳緩存，但在作業(yè)開(kāi)始時(shí)從不下載緩存，請(qǐng)使用?cache:policy:push。
當(dāng)您有許多使用相同緩存并行執(zhí)行的作業(yè)時(shí)，請(qǐng)使用?pull?策略。 此策略可加快作業(yè)執(zhí)行速度并減少緩存服務(wù)器上的負(fù)載。 您可以使用帶有?push?策略的作業(yè)來(lái)構(gòu)建緩存。
必須與?cache: path?一起使用，否則不會(huì)緩存任何內(nèi)容。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：
pullpush-
pull-push（默認(rèn)）
cache:policy?示例：
prepare-dependencies-job:
stage: build
cache:
key: gems
paths:
- vendor/bundle
policy: push
script:
- echo "This job only downloads dependencies and builds the cache."
- echo "Downloading dependencies..."
faster-test-job:
stage: test
cache:
key: gems
paths:
- vendor/bundle
policy: pull
script:
- echo "This job script uses the cache, but does not update it."
- echo "Running tests..."dependencies
使用?dependencies?關(guān)鍵字定義要從中獲取產(chǎn)物的作業(yè)列表。 您還可以設(shè)置一個(gè)作業(yè)以完全不下載任何產(chǎn)物。
如果您不使用?dependencies，則前一階段的所有產(chǎn)物都會(huì)傳遞給每個(gè)作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 從中獲取產(chǎn)物的作業(yè)名稱(chēng)。
- 一個(gè)空數(shù)組 (
[])，用于將作業(yè)配置為不下載任何產(chǎn)物。
dependencies?示例：
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在這個(gè)例子中，兩個(gè)作業(yè)有產(chǎn)物：build osx?和?build linux。當(dāng)執(zhí)行?test osx?時(shí)，build osx?的產(chǎn)物被下載并在構(gòu)建的上下文中提取。 同樣的事情發(fā)生在?test linux?和?build linux?的產(chǎn)物上。
由于?stage?優(yōu)先級(jí)，deploy?作業(yè)從所有以前的作業(yè)下載產(chǎn)物。
額外細(xì)節(jié)：
- 作業(yè)狀態(tài)無(wú)關(guān)緊要。如果作業(yè)失敗或者是未觸發(fā)的手動(dòng)作業(yè)，則不會(huì)發(fā)生錯(cuò)誤。
- 如果依賴作業(yè)的產(chǎn)物是已過(guò)期或已刪除，則作業(yè)失敗。
artifacts
使用?artifacts?指定在作業(yè)?succeeds, fails, 或 always?時(shí)附加到作業(yè)的文件和目錄列表。
作業(yè)完成后，產(chǎn)物將發(fā)送到 GitLab。如果大小不大于最大產(chǎn)物大小，它們可以在 GitLab UI 中下載。
默認(rèn)情況下，后期的作業(yè)會(huì)自動(dòng)下載早期作業(yè)創(chuàng)建的所有產(chǎn)物。您可以使用?dependencies?控制作業(yè)中的產(chǎn)物下載行為。
使用?needs?關(guān)鍵字時(shí)，作業(yè)只能從?needs?配置中定義的作業(yè)下載產(chǎn)物。
默認(rèn)只收集成功作業(yè)的作業(yè)產(chǎn)物，產(chǎn)物在緩存后恢復(fù)。
閱讀有關(guān)產(chǎn)物的更多信息。
artifacts:exclude
exclude?可以防止將文件添加到產(chǎn)物存檔中。
類(lèi)似于?artifacts:paths，exclude?路徑是相對(duì)于項(xiàng)目目錄的。您可以使用使用 glob 或?doublestar.PathMatch?模式的通配符。
例如，要將所有文件存儲(chǔ)在?binaries/?中，但不存儲(chǔ)位于?binaries/?子目錄中的?*.o?文件：
artifacts:
paths:
- binaries/
exclude:
- binaries/**/*.o與?artifacts:paths?不同，exclude?路徑不是遞歸的。要排除目錄的所有內(nèi)容，您可以顯式匹配它們而不是匹配目錄本身。
例如，要將所有文件存儲(chǔ)在?binaries/?中，但不存儲(chǔ)在?temp/?子目錄中：
artifacts:
paths:
- binaries/
exclude:
- binaries/temp/**/*與?artifacts:untracked?匹配的文件也可以使用?artifacts:exclude?排除。
artifacts:expire_in
- 引入于 13.0 版本，在功能標(biāo)志后默認(rèn)禁用，無(wú)論到期時(shí)間如何，都會(huì)保留最新的作業(yè)產(chǎn)物。
- 默認(rèn)啟用于 13.4.
- 引入于 13.8 版本，可以在項(xiàng)目級(jí)別禁用保持最新的作業(yè)產(chǎn)物。
- 引入于 13.9 版本，可以在實(shí)例范圍內(nèi)禁用保持最新的作業(yè)產(chǎn)物。
- 引入于 13.12 版本，無(wú)論到期時(shí)間如何，都會(huì)保留最新的流水線產(chǎn)物。
使用?expire_in?指定作業(yè)產(chǎn)物在它們過(guò)期和被刪除之前存儲(chǔ)多長(zhǎng)時(shí)間。expire_in?設(shè)置不會(huì)影響：
- 來(lái)自最新作業(yè)的產(chǎn)物，除非保留最新的作業(yè)產(chǎn)物：
- 在項(xiàng)目級(jí)別禁用。
- 在實(shí)例范圍禁用。
-
流水線產(chǎn)物。無(wú)法為這些指定到期日期：
- 來(lái)自最新流水線的流水線產(chǎn)物將永遠(yuǎn)保留。
- 一周后刪除其他流水線產(chǎn)物。
expire_in?的值是以秒為單位的經(jīng)過(guò)時(shí)間，除非提供了單位。有效值包括：
'42'42 seconds3 mins 4 sec2 hrs 20 min2h20min6 mos 1 day47 yrs 6 mos and 4d3 weeks and 2 daysnever
要在上傳后一周使產(chǎn)物過(guò)期：
job:
artifacts:
expire_in: 1 week當(dāng)產(chǎn)物上傳并存儲(chǔ)在極狐GitLab 上時(shí)，到期時(shí)間段開(kāi)始。如果未定義到期時(shí)間，則默認(rèn)為實(shí)例范圍設(shè)置（默認(rèn)為 30 天）。
要覆蓋到期日期并保護(hù)產(chǎn)物不被自動(dòng)刪除：
- 使用作業(yè)頁(yè)面上的保留按鈕。
- 在 13.3 及更高版本中，將?
expire_in?的值設(shè)置為?never。
過(guò)期后，產(chǎn)物默認(rèn)每小時(shí)刪除一次（使用 cron 作業(yè)），并且不再可訪問(wèn)。
artifacts:expose_as
使用?expose_as?關(guān)鍵字在合并請(qǐng)求?UI 中公開(kāi)作業(yè)產(chǎn)物。
例如，要匹配單個(gè)文件：
test:
script: ["echo 'test' > file.txt"]
artifacts:
expose_as: 'artifact 1'
paths: ['file.txt']通過(guò)此配置，極狐GitLab 添加了一個(gè)鏈接?artifact 1?到指向?file1.txt?的相關(guān)合并請(qǐng)求。要訪問(wèn)該鏈接，請(qǐng)選擇合并請(qǐng)求概覽中流水線圖下方的?查看已展示的產(chǎn)物。
匹配整個(gè)目錄的示例：
test:
script: ["mkdir test && echo 'test' > test/file.txt"]
artifacts:
expose_as: 'artifact 1'
paths: ['test/']請(qǐng)注意以下事項(xiàng)：
- 使用變量定義?
artifacts:paths?時(shí)，不會(huì)在合并請(qǐng)求 UI 中顯示產(chǎn)物。 - 每個(gè)合并請(qǐng)求最多可以公開(kāi) 10 個(gè)作業(yè)產(chǎn)物。
- 不支持全局模式。
- 如果指定了目錄，如果目錄中有多個(gè)文件，則鏈接指向作業(yè)產(chǎn)物瀏覽器。
- 對(duì)于帶有?
.html、.htm、.txt、.json、.xml?和?.log?擴(kuò)展名的公開(kāi)單個(gè)文件產(chǎn)物，如果 GitLab Pages：- 啟用，系統(tǒng)自動(dòng)呈現(xiàn)產(chǎn)物。
- 未啟用，文件顯示在產(chǎn)物瀏覽器中。
artifacts:name
使用?name?指令來(lái)定義創(chuàng)建的產(chǎn)物存檔的名稱(chēng)。您可以為每個(gè)存檔指定唯一的名稱(chēng)。artifacts:name?變量可以使用任何預(yù)定義變量。 默認(rèn)名稱(chēng)是?artifacts，下載后會(huì)變成?artifacts.zip。
要使用當(dāng)前作業(yè)的名稱(chēng)創(chuàng)建存檔：
job:
artifacts:
name: "$CI_JOB_NAME"
paths:
- binaries/要使用當(dāng)前分支或標(biāo)記的名稱(chēng)創(chuàng)建檔案，僅包括二進(jìn)制目錄：
job:
artifacts:
name: "$CI_COMMIT_REF_NAME"
paths:
- binaries/如果您的分支名稱(chēng)包含正斜杠（例如feature/my-feature），建議使用?$CI_COMMIT_REF_SLUG?而不是?$CI_COMMIT_REF_NAME?來(lái)正確命名產(chǎn)物。
要使用當(dāng)前作業(yè)的名稱(chēng)和當(dāng)前的分支或標(biāo)記創(chuàng)建僅包含二進(jìn)制文件目錄的存檔：
job:
artifacts:
name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
paths:
- binaries/要使用當(dāng)前?stage?和分支名稱(chēng)的名稱(chēng)創(chuàng)建存檔：
job:
artifacts:
name: "$CI_JOB_STAGE-$CI_COMMIT_REF_NAME"
paths:
- binaries/如果您使用?Windows Batch?運(yùn)行您的 shell 腳本，你需要用?%?替換?$：
job:
artifacts:
name: "%CI_JOB_STAGE%-%CI_COMMIT_REF_NAME%"
paths:
- binaries/如果您使用?Windows PowerShell?運(yùn)行您的 shell 腳本，你需要用?$env:?替換?$：
job:
artifacts:
name: "$env:CI_JOB_STAGE-$env:CI_COMMIT_REF_NAME"
paths:
- binaries/artifacts:paths
路徑相對(duì)于項(xiàng)目目錄 ($CI_PROJECT_DIR)，不能直接鏈接到項(xiàng)目目錄之外。您可以使用 glob 模式的通配符和：
- 在 GitLab Runner 13.0 和更高版本，doublestar.Glob。
- 在 GitLab Runner 12.10 和更早版本，filepath.Match。
要限制特定作業(yè)從哪些作業(yè)獲取工件，請(qǐng)參閱?dependencies。
發(fā)送?binaries?和?.config?中的所有文件：
artifacts:
paths:
- binaries/
- .config要禁用產(chǎn)物傳遞，請(qǐng)使用空?dependencies?定義作業(yè)：
job:
stage: build
script: make build
dependencies: []您可能只想為標(biāo)簽版本創(chuàng)建產(chǎn)物，以避免使用臨時(shí)構(gòu)建產(chǎn)物填充構(gòu)建服務(wù)器存儲(chǔ)。
僅為標(biāo)簽創(chuàng)建產(chǎn)物（default-job?不創(chuàng)建產(chǎn)物）：
default-job:
script:
- mvn test -U
rules:
- if: $CI_COMMIT_BRANCH
release-job:
script:
- mvn package -U
artifacts:
paths:
- target/*.war
rules:
- if: $CI_COMMIT_TAG您也可以對(duì)目錄使用通配符。例如，如果您想獲取以?xyz?結(jié)尾的目錄中的所有文件：
job:
artifacts:
paths:
- path/*xyz/*artifacts:public
- 引入于 13.8 版本
- 部署在功能標(biāo)志后默認(rèn)禁用
- 推薦用于生產(chǎn)用途
FLAG: 在自我管理實(shí)例上，默認(rèn)情況下此功能不可用。 要使其可用，請(qǐng)讓管理員啟用命名為?non_public_artifacts?的功能標(biāo)志?。在 SaaS 版上，此功能不可用。
使用?artifacts:public?來(lái)確定作業(yè)產(chǎn)物是否應(yīng)該公開(kāi)可用。
artifacts:public?的默認(rèn)值為?true，這意味著匿名和訪客用戶可以下載公共流水線中的產(chǎn)物：
artifacts:
public: true要拒絕匿名用戶和來(lái)賓用戶對(duì)公共流水線中的產(chǎn)物的讀取訪問(wèn)權(quán)限，請(qǐng)將?artifacts:public?設(shè)置為?false：
artifacts:
public: falseartifacts:reports
使用?artifacts:reports：
- 從作業(yè)中收集測(cè)試報(bào)告、代碼質(zhì)量報(bào)告和安全報(bào)告。
- 在合并請(qǐng)求、流水線視圖和安全儀表盤(pán)中公開(kāi)這些報(bào)告。
無(wú)論作業(yè)結(jié)果如何（成功或失?。?，都會(huì)收集測(cè)試報(bào)告。 您可以使用?artifacts:expire_in?為其產(chǎn)物設(shè)置到期日期。
某些?artifacts:reports?類(lèi)型可以由同一流水線中的多個(gè)作業(yè)生成，并由每個(gè)作業(yè)的合并請(qǐng)求或流水線功能使用。
為了能夠?yàn)g覽報(bào)告輸出文件，請(qǐng)包含?artifacts:paths?關(guān)鍵字。請(qǐng)注意，將上傳和存儲(chǔ)產(chǎn)物兩次。
NOTE: 不支持使用來(lái)自子流水線的產(chǎn)物的父流水線的組合報(bào)告。
artifacts:reports:accessibility?(FREE)
accessibility?報(bào)告使用?pa11y?報(bào)告合并請(qǐng)求中引入的更改對(duì)可訪問(wèn)性的影響。
極狐GitLab 可以在合并請(qǐng)求可訪問(wèn)性部件中顯示一個(gè)或多個(gè)報(bào)告的結(jié)果。
artifacts:reports:api_fuzzing?(ULTIMATE)
api_fuzzing?報(bào)告收集了 API Fuzzing bug 作為產(chǎn)物。
artifacts:reports:browser_performance?(PREMIUM)
- 名稱(chēng)從?
artifacts:reports:performance?改為現(xiàn)名稱(chēng)于 14.0 版本。
browser_performance?報(bào)告收集瀏覽器性能測(cè)試指標(biāo)作為產(chǎn)物。
極狐GitLab 可以在合并請(qǐng)求中顯示一份報(bào)告的結(jié)果。
極狐GitLab 無(wú)法顯示多個(gè)?browser_performance?報(bào)告的組合結(jié)果。
artifacts:reports:cluster_image_scanning?(ULTIMATE)
- 引入于 14.1 版本。
- 需要 GitLab Runner 14.1 和更高版本。
cluster_image_scanning?報(bào)告收集?CLUSTER_IMAGE_SCANNING?漏洞作為產(chǎn)物。
artifacts:reports:cobertura
cobertura?報(bào)告收集 Cobertura 覆蓋 XML 文件。 收集的 Cobertura 覆蓋率報(bào)告作為產(chǎn)物上傳到極狐GitLab 并顯示在合并請(qǐng)求中。
Cobertura 最初是為 Java 開(kāi)發(fā)的，但有許多第三方移植用于其他語(yǔ)言，如 JavaScript、Python、Ruby 等。
artifacts:reports:codequality
codequality?報(bào)告收集代碼質(zhì)量問(wèn)題作為產(chǎn)物。
收集的代碼質(zhì)量報(bào)告作為產(chǎn)物上傳到極狐GitLab，并在合并請(qǐng)求中匯總。
artifacts:reports:container_scanning?(ULTIMATE)
container_scanning?報(bào)告收集容器掃描漏洞作為產(chǎn)物。
收集的容器掃描報(bào)告作為產(chǎn)物上傳到極狐GitLab，并在合并請(qǐng)求和流水線視圖中匯總。它還用于為安全儀表盤(pán)提供數(shù)據(jù)。
artifacts:reports:coverage_fuzzing?(ULTIMATE)
coverage_fuzzing?報(bào)告收集 coverage fuzzing bug。 收集到的覆蓋模糊報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:dast?(ULTIMATE)
dast?報(bào)告收集 DAST 漏洞。收集的 DAST 報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:dependency_scanning?(ULTIMATE)
dependency_scanning` 報(bào)告收集依賴掃描漏洞。 收集到的依賴掃描報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:dotenv
收集的變量被注冊(cè)為作業(yè)的運(yùn)行時(shí)創(chuàng)建的變量，這對(duì)于作業(yè)完成后設(shè)置動(dòng)態(tài)環(huán)境 URL 很有用。
原始 dotenv 規(guī)則?有幾個(gè)例外：
- 變量鍵只能包含字母、數(shù)字和下劃線 (
_)。 -
.env?文件的最大大小為 5 KB。 - 在 13.5 及更早版本中，最大繼承變量數(shù)為 10。
- 在 13.6 及更高版本中，最大繼承變量數(shù)為 20。
- 不支持
.env?文件中的變量替換。 -
.env?文件不能有空行或注釋?zhuān)ㄒ?#?開(kāi)頭）。 -
env?文件中的鍵值不能有空格或換行符 (\n)，包括使用單引號(hào)或雙引號(hào)時(shí)。 - 不支持在解析過(guò)程中引用轉(zhuǎn)義 (
key = 'value'?->?{key: "value"})。
artifacts:reports:junit
junit?報(bào)告收集JUnit 報(bào)告格式 XML 文件。 收集到的單元測(cè)試報(bào)告作為產(chǎn)物上傳到極狐GitLab。盡管 JUnit 最初是用 Java 開(kāi)發(fā)的，但也有許多其他語(yǔ)言（如 JavaScript、Python 和 Ruby）的第三方端口。
下面是從 Ruby 的 RSpec 測(cè)試工具收集 JUnit 報(bào)告格式 XML 文件的示例：
rspec:
stage: test
script:
- bundle install
- rspec --format RspecJunitFormatter --out rspec.xml
artifacts:
reports:
junit: rspec.xml一些 JUnit 工具導(dǎo)出到多個(gè) XML 文件。您可以在單個(gè)作業(yè)中指定多個(gè)測(cè)試報(bào)告路徑以將它們連接到一個(gè)文件中。使用：
- 文件名模式（
junit: rspec-*.xml）。 - 文件名數(shù)組（
junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]）。 - 兩者的組合（
junit: [rspec.xml, test-results/TEST-*.xml]）。
artifacts:reports:license_scanning?(ULTIMATE)
許可證合規(guī)報(bào)告收集許可證。許可證合規(guī)報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:load_performance?(PREMIUM)
load_performance?報(bào)告收集負(fù)載性能測(cè)試指標(biāo)作為產(chǎn)物。
該報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:metrics?(PREMIUM)
metrics?報(bào)告收集 Metrics 作為產(chǎn)物。
收集的指標(biāo)報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:reports:requirements?(ULTIMATE)
requirements?報(bào)告收集?requirements.json?文件作為產(chǎn)物。
收集到的需求報(bào)告作為產(chǎn)物上傳到極狐GitLab，現(xiàn)有的需求被標(biāo)記為 Satisfied。
artifacts:reports:sast
sast?報(bào)告收集 SAST 漏洞作為產(chǎn)物。
收集的 SAST 報(bào)告作為產(chǎn)物上傳到極狐GitLab，并在合并請(qǐng)求和流水線視圖中匯總。它還用于為安全儀表盤(pán)提供數(shù)據(jù)。
artifacts:reports:secret_detection
secret-detection?報(bào)告收集檢測(cè)到的 secret 作為產(chǎn)物。
收集到的 secret 檢測(cè)報(bào)告作為產(chǎn)物上傳到極狐GitLab，并在合并請(qǐng)求和流水線視圖中匯總。它還用于為安全儀表盤(pán)提供數(shù)據(jù)。
artifacts:reports:terraform
- 引入于 13.0 版本。
- 需要極狐GitLab Runner 11.5 及更高版本。
terraform?報(bào)告獲取 Terraform?tfplan.json?文件。刪除憑據(jù)所需的 JQ 流程。收集的 Terraform 計(jì)劃報(bào)告作為產(chǎn)物上傳到極狐GitLab。
artifacts:untracked
使用?artifacts:untracked?將所有 Git 未跟蹤文件添加為產(chǎn)物（以及在?artifacts:paths?中定義的路徑）。artifacts:untracked?忽略倉(cāng)庫(kù)的?.gitignore?文件中的配置。
發(fā)送所有 Git 未跟蹤文件：
artifacts:
untracked: true發(fā)送所有 Git 未跟蹤文件和?binaries?中的文件：
artifacts:
untracked: true
paths:
- binaries/發(fā)送所有未跟蹤的文件，但排除?*.txt：
artifacts:
untracked: true
exclude:
- "*.txt"artifacts:when
使用?artifacts:when?在作業(yè)失敗時(shí)上傳產(chǎn)物。
artifacts:when?可以設(shè)置為以下值之一：
-
on_success（默認(rèn)）：僅在作業(yè)成功時(shí)上傳產(chǎn)物。 -
on_failure：僅在作業(yè)失敗時(shí)上傳產(chǎn)物。 -
always：始終上傳產(chǎn)物。例如，當(dāng)需要對(duì)失敗的測(cè)試進(jìn)行故障排除時(shí)，很有用。
例如，僅在作業(yè)失敗時(shí)上傳產(chǎn)物：
job:
artifacts:
when: on_failurecoverage
使用帶有自定義正則表達(dá)式的?coverage?來(lái)配置如何從作業(yè)輸出中提取代碼覆蓋率。如果作業(yè)輸出中至少有一行與正則表達(dá)式匹配，則覆蓋率會(huì)顯示在 UI 中。
為了提取匹配行中的代碼覆蓋率值，極狐GitLab 使用以下正則表達(dá)式：\d+(\.\d+)?。
可能的輸入：正則表達(dá)式。必須以/開(kāi)頭和結(jié)尾。
coverage?示例：
job1:
script: rspec
coverage: '/Code coverage: \d+\.\d+/'在這個(gè)例子中：
- 系統(tǒng)檢查作業(yè)日志中是否有與正則表達(dá)式匹配的行。像?
Code coverage: 67.89?這樣的行會(huì)匹配。 - 然后檢查該行以找到與?
\d+(\.\d+)??的匹配項(xiàng)。上面的示例匹配行給出了?67.89?的代碼覆蓋率。
額外細(xì)節(jié)：
- 如果作業(yè)輸出中有多個(gè)匹配的行，則使用最后一行。
- 如果單行中有多個(gè)匹配項(xiàng)，則搜索使用最后一個(gè)匹配項(xiàng)。
- 如果在匹配的片段中找到多個(gè)覆蓋率數(shù)字，則使用第一個(gè)。
- 刪除前導(dǎo)零。
- 子流水線?的覆蓋輸出未記錄或顯示。
dast_configuration?(ULTIMATE)
引入于 14.1 版本。
使用?dast_configuration?關(guān)鍵字指定要在 CI/CD 配置中使用的站點(diǎn)配置文件和掃描程序配置文件。必須首先在項(xiàng)目中創(chuàng)建這兩個(gè)配置文件。作業(yè)的階段必須是?dast。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。只能作為作業(yè)的一部分使用。
可能的輸入：site_profile?和?scanner_profile?各一個(gè)。
- 使用?
site_profile?指定要在作業(yè)中使用的站點(diǎn)配置文件。 - 使用?
scanner_profile?指定要在作業(yè)中使用的掃描儀配置文件。
dast_configuration?示例：
stages:
- build
- dast
include:
- template: DAST.gitlab-ci.yml
dast:
dast_configuration:
site_profile: "Example Co"
scanner_profile: "Quick Passive Test"在此示例中，dast?作業(yè)擴(kuò)展了添加了?include:?關(guān)鍵字的?dast?配置，以選擇特定的站點(diǎn)配置文件和掃描儀配置文件。
額外細(xì)節(jié)：
- 站點(diǎn)配置文件或掃描儀配置文件中包含的設(shè)置優(yōu)先于 DAST 模板中包含的設(shè)置。
retry
使用?retry?配置作業(yè)失敗時(shí)重試的次數(shù)。如果未定義，則默認(rèn)為?0?并且作業(yè)不會(huì)重試。
當(dāng)作業(yè)失敗時(shí)，該作業(yè)最多再處理兩次，直到成功或達(dá)到最大重試次數(shù)。
默認(rèn)情況下，所有失敗類(lèi)型都會(huì)導(dǎo)致重試作業(yè)。使用?retry:when?選擇要重試的失敗。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：0（默認(rèn)）、1?或2。
retry?示例：
test:
script: rspec
retry: 2retry:when
使用?retry:when?和?retry:max?僅針對(duì)特定的失敗情況重試作業(yè)。retry:max?是最大重試次數(shù)，如?retry，可以是?0、1?或?2。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：?jiǎn)我还收项?lèi)型，或一個(gè)或多個(gè)故障類(lèi)型的數(shù)組：
-
always：任何失敗重試（默認(rèn)）。 -
unknown_failure：當(dāng)失敗原因未知時(shí)重試。 -
script_failure：腳本失敗時(shí)重試。 -
api_failure：在 API 失敗時(shí)重試。 -
stuck_or_timeout_failure：當(dāng)作業(yè)卡住或超時(shí)時(shí)重試。 -
runner_system_failure：如果 runner 系統(tǒng)出現(xiàn)故障（例如，作業(yè)設(shè)置失?。?，請(qǐng)重試。 -
runner_unsupported：如果 runner 不受支持，請(qǐng)重試。 -
stale_schedule：如果無(wú)法執(zhí)行延遲的作業(yè)，請(qǐng)重試。 -
job_execution_timeout：如果腳本超過(guò)為作業(yè)設(shè)置的最大執(zhí)行時(shí)間，請(qǐng)重試。 -
archived_failure：如果作業(yè)已存檔且無(wú)法運(yùn)行，請(qǐng)重試。 -
unmet_prerequisites：如果作業(yè)未能完成先決任務(wù)，請(qǐng)重試。 -
scheduler_failure：如果 scheduler 未能將作業(yè)分配給 runner，請(qǐng)重試。 -
data_integrity_failure：如果檢測(cè)到結(jié)構(gòu)完整性問(wèn)題，請(qǐng)重試。
retry:when?示例（單一故障型）:
test:
script: rspec
retry:
max: 2
when: runner_system_failure果存在除 runner 系統(tǒng)故障以外的故障，則不會(huì)重試作業(yè)。
retry:when?示例?（故障類(lèi)型數(shù)組）:
test:
script: rspec
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failuretimeout
使用?timeout?為特定作業(yè)配置超時(shí)。如果作業(yè)運(yùn)行的時(shí)間超過(guò)超時(shí)時(shí)間，作業(yè)將失敗。
作業(yè)級(jí)超時(shí)可以長(zhǎng)于項(xiàng)目級(jí)超時(shí)。但不能超過(guò) runner 的超時(shí)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分中使用。
可能的輸入：用自然語(yǔ)言編寫(xiě)的一段時(shí)間。例如，以下都是等價(jià)的：
3600 seconds60 minutesone hour
timeout?示例：
build:
script: build.sh
timeout: 3 hours 30 minutes
test:
script: rspec
timeout: 3h 30mparallel
使用?parallel?配置并行運(yùn)行的作業(yè)實(shí)例數(shù)。 該值可以是 2 到 50。
parallel?關(guān)鍵字創(chuàng)建并行運(yùn)行的同一作業(yè)的 N 個(gè)實(shí)例。 它們從?job_name 1/N?到?job_name N/N?按順序命名：
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：從?2?到?50?的數(shù)值。
parallel?示例：
test:
script: rspec
parallel: 5此示例創(chuàng)建了 5 個(gè)并行運(yùn)行的作業(yè)，名為?test 1/5?到?test 5/5。
額外細(xì)節(jié)：
- 每個(gè)并行作業(yè)都有一個(gè)?
CI_NODE_INDEX?和?CI_NODE_TOTAL?預(yù)定義 CI/CD 變量集。
parallel:matrix
使用?parallel:matrix?在單個(gè)流水線中并行運(yùn)行作業(yè)多次，但對(duì)于作業(yè)的每個(gè)實(shí)例使用不同的變量值。
必須存在多個(gè) runner，或者必須將單個(gè) runner 配置為同時(shí)運(yùn)行多個(gè)作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：變量哈希數(shù)組：
- 變量名只能使用數(shù)字、字母和下劃線 (
_)。 - 值必須是字符串或字符串?dāng)?shù)組。
- 排列數(shù)不能超過(guò) 50。
parallel:matrix?示例：
deploystacks:
stage: deploy
script:
- bin/deploy
parallel:
matrix:
- PROVIDER: aws
STACK:
- monitoring
- app1
- app2
- PROVIDER: ovh
STACK: [monitoring, backup, app]
- PROVIDER: [gcp, vultr]
STACK: [data, processing]該示例生成 10 個(gè)并行的?deploystacks?作業(yè)，每個(gè)作業(yè)具有不同的?PROVIDER?和?STACK?值：
deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [ovh, app]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]trigger
使用?trigger?啟動(dòng)下游流水線：
- 多項(xiàng)目流水線。
- 子流水線。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 對(duì)于多項(xiàng)目流水線，指向下游項(xiàng)目的路徑。
- 對(duì)于子流水線，子流水線 CI/CD 配置文件的路徑。
多項(xiàng)目流水線的?trigger?示例：
rspec:
stage: test
script: bundle exec rspec
staging:
stage: deploy
trigger: my/deployment子流水線的?trigger?示例：
trigger_job:
trigger:
include: path/to/child-pipeline.yml額外細(xì)節(jié)：
- 帶有?
trigger?的作業(yè)只能使用有限的關(guān)鍵字集。例如，您不能使用?script、before_script?或?after_script?運(yùn)行命令。 - 您不能使用 API 來(lái)啟動(dòng)?
when:manual?觸發(fā)器作業(yè)。 - 在 13.5 及更高版本中，您可以在與?
trigger?相同的作業(yè)中使用?when:manual。 在 13.4 及更早版本中，將它們一起使用會(huì)導(dǎo)致錯(cuò)誤?jobs:#{job-name} when should be on_success, on_failure or always。 - 在 13.2 及更高版本中，您可以在流水線圖中查看哪個(gè)作業(yè)觸發(fā)了下游流水線。
- 手動(dòng)流水線變量和計(jì)劃流水線變量默認(rèn)情況下不傳遞給下游流水線。使用?trigger:forward?將這些變量轉(zhuǎn)發(fā)到下游流水線。
trigger:strategy
使用?trigger:strategy?強(qiáng)制?trigger?作業(yè)在標(biāo)記為?success?之前等待下游流水線完成。
此行為與默認(rèn)行為不同，默認(rèn)行為是在創(chuàng)建下游流水線后立即將?trigger?作業(yè)標(biāo)記為?success。
此設(shè)置使您的流水線執(zhí)行線性而不是并行。
trigger:strategy?示例：
trigger_job:
trigger:
include: path/to/child-pipeline.yml
strategy: depend在此示例中，后續(xù)階段的作業(yè)在開(kāi)始之前等待觸發(fā)的流水線成功完成。
interruptible
如果在作業(yè)完成之前新流水線啟動(dòng)時(shí)應(yīng)取消作業(yè)，請(qǐng)使用?interruptible。
如果禁用自動(dòng)取消冗余流水線，則此關(guān)鍵字無(wú)效。啟用后，在為同一分支上的新更改啟動(dòng)流水線時(shí)，會(huì)取消正在運(yùn)行的具有?interruptible: true?的作業(yè)。
在帶有?interruptible: false?的作業(yè)開(kāi)始后，您無(wú)法取消后續(xù)作業(yè)。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分或在?default:?部分?中使用。
可能的輸入：true?或?false（默認(rèn)）。
interruptible?示例：
stages:
- stage1
- stage2
- stage3
step-1:
stage: stage1
script:
- echo "Can be canceled."
interruptible: true
step-2:
stage: stage2
script:
- echo "Can not be canceled."
step-3:
stage: stage3
script:
- echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
interruptible: true在這個(gè)例子中，一個(gè)新的流水線導(dǎo)致一個(gè)正在運(yùn)行的流水線：
- 取消，如果只有?
step-1?正在運(yùn)行或掛起。 - 未取消，在?
step-2?開(kāi)始后。
額外細(xì)節(jié)：
- 如果作業(yè)在開(kāi)始后可以安全取消，則僅設(shè)置?
interruptible: true，例如構(gòu)建作業(yè)。通常不應(yīng)取消部署作業(yè)，以防止部分部署。 - 要完全取消正在運(yùn)行的流水線，所有作業(yè)必須具有?
interruptible: true，或?interruptible: false?作業(yè)必須尚未啟動(dòng)。
resource_group
使用?resource_group?創(chuàng)建一個(gè)資源組，以確保同一項(xiàng)目的不同流水線之間的作業(yè)是互斥的。
例如，如果屬于同一資源組的多個(gè)作業(yè)同時(shí)排隊(duì)，則只有其中一個(gè)作業(yè)啟動(dòng)。其他作業(yè)一直等到?resource_group?空閑。
資源組的行為類(lèi)似于其他編程語(yǔ)言中的信號(hào)量。
您可以為每個(gè)環(huán)境定義多個(gè)資源組。例如，在部署到物理設(shè)備時(shí)，您可能有多個(gè)物理設(shè)備。 每個(gè)設(shè)備都可以部署到，但在任何給定時(shí)間每個(gè)設(shè)備只能進(jìn)行一次部署。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：只有字母、數(shù)字、-、_、/、$、{、}、.?和空格。不能以/開(kāi)頭或結(jié)尾。
resource_group?示例：
deploy-to-production:
script: deploy
resource_group: production在這個(gè)例子中，兩個(gè)獨(dú)立流水線中的兩個(gè)?deploy-to-production?作業(yè)永遠(yuǎn)不能同時(shí)運(yùn)行。因此，您可以確保并發(fā)部署永遠(yuǎn)不會(huì)發(fā)生在生產(chǎn)環(huán)境中。
release
使用?release?創(chuàng)建一個(gè)發(fā)布。
發(fā)布作業(yè)必須有權(quán)訪問(wèn)?release-cli，其必須在?$PATH?中。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：release:?子鍵：
- tag_name
- description
- name（可選）
- ref（可選）
- milestones（可選）
- released_at（可選）
- assets:links（可選）
release?關(guān)鍵字示例：
release_job:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $CI_COMMIT_TAG # Run this job when a tag is created manually
script:
- echo "Running the release job."
release:
tag_name: $CI_COMMIT_TAG
name: 'Release $CI_COMMIT_TAG'
description: 'Release created using the release-cli.'此示例創(chuàng)建一個(gè)版本：
- 當(dāng)你推送一個(gè) Git 標(biāo)簽時(shí)。
- 當(dāng)您在?倉(cāng)庫(kù) > 標(biāo)簽?的 UI 中添加 Git 標(biāo)簽時(shí)。
額外細(xì)節(jié)：
-
除?trigger?作業(yè)外，所有發(fā)布作業(yè)都必須包含?
script?關(guān)鍵字。發(fā)布作業(yè)可以使用腳本命令的輸出。如果不需要腳本，可以使用占位符：script: - echo 'release job' -
release?部分在?script?關(guān)鍵字之后和?after_script?之前執(zhí)行。 -
僅當(dāng)作業(yè)的主腳本成功時(shí)才會(huì)創(chuàng)建發(fā)布。
-
如果發(fā)布已經(jīng)存在，則不會(huì)更新并且?guī)в?
release?關(guān)鍵字的作業(yè)失敗。 -
如果你使用 Shell executor 或在注冊(cè) runner 的服務(wù)器上安裝?
release-cli。
release:tag_name
必需的。發(fā)布的 Git 標(biāo)簽。
如果項(xiàng)目中尚不存在該標(biāo)簽，則在發(fā)布的同時(shí)創(chuàng)建該標(biāo)簽。 新標(biāo)簽使用與流水線關(guān)聯(lián)的 SHA。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：標(biāo)簽名稱(chēng)?？梢允褂?CI/CD 流水線。
release:tag_name?示例：
在項(xiàng)目中添加新標(biāo)簽時(shí)創(chuàng)建發(fā)布：
- 使用?
$CI_COMMIT_TAG?CI/CD 變量作為?tag_name。 - 使用?rules:if?或?only: tags?將作業(yè)配置為僅針對(duì)新標(biāo)簽運(yùn)行。
job:
script: echo 'Running the release job for the new tag.'
release:
tag_name: $CI_COMMIT_TAG
description: 'Release description'
rules:
- if: $CI_COMMIT_TAG要同時(shí)創(chuàng)建發(fā)布和新標(biāo)簽，您的?rules?或?only?應(yīng)該不應(yīng)將作業(yè)配置為僅針對(duì)新標(biāo)簽運(yùn)行。語(yǔ)義版本控制示例：
job:
script: echo 'Running the release job and creating a new tag.'
release:
tag_name: ${MAJOR}_${MINOR}_${REVISION}
description: 'Release description'
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"release:name
版本名稱(chēng)。如果省略，則使用?release: tag_name?的值填充。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：一個(gè)文本字符串。
release:name?示例：
release_job:
stage: release
release:
name: 'Release $CI_COMMIT_TAG'release:description
發(fā)布的詳細(xì)說(shuō)明。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 帶有詳細(xì)描述的字符串。
- 包含描述的文件的路徑。在 13.7 中引入。
- 文件位置必須相對(duì)于項(xiàng)目目錄 (
$CI_PROJECT_DIR)。 - 如果文件是一個(gè)符號(hào)鏈接，它必須在?
$CI_PROJECT_DIR?中。 -
./path/to/file?和文件名不能包含空格。
- 文件位置必須相對(duì)于項(xiàng)目目錄 (
release:description?示例：
job:
release:
tag_name: ${MAJOR}_${MINOR}_${REVISION}
description: './path/to/CHANGELOG.md'release:ref
如果?release: tag_name?還不存在，作為發(fā)布的?ref。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
- 提交 SHA、另一個(gè)標(biāo)簽名稱(chēng)或分支名稱(chēng)。
release:milestones
與發(fā)布相關(guān)的每個(gè)里程碑的標(biāo)題。
release:released_at
發(fā)布準(zhǔn)備就緒的日期和時(shí)間。
可能的輸入：
- 用引號(hào)括起來(lái)并以 ISO 8601 格式表示的日期。
release:released_at?示例：
released_at: '2021-03-15T08:00:00Z'額外細(xì)節(jié)：
- 如果未定義，則使用當(dāng)前日期和時(shí)間。
release:assets:links
引入于 13.12 版本。
使用?release:assets:links?在發(fā)布中包含?assets 鏈接。
需要?release-cli?版本 v0.4.0 或更高版本。
release:assets:links?示例：
assets:
links:
- name: 'asset1'
url: 'https://example.com/assets/1'
- name: 'asset2'
url: 'https://example.com/assets/2'
filepath: '/pretty/url/1' # optional
link_type: 'other' # optionalsecrets?(PREMIUM)
引入于 13.4 版本。
使用?secrets?將?CI/CD secret?指定為：
- 從外部 secret 提供商處檢索。
- 在作業(yè)中作為?CI/CD 變量（file?類(lèi)型?默認(rèn)情況下提供）。
此關(guān)鍵字必須與?secrets:vault?一起使用。
secrets:vault
- 引入于 13.4 版本和 GitLab Runner 13.4。
使用?secrets:vault?指定由?HashiCorp Vault?提供的 secret。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
-
engine:name：secret engine 的名稱(chēng)。 -
engine:path：secret engine 的路徑。 -
path：secret 的路徑。 -
field：存儲(chǔ)密碼的字段的名稱(chēng)。
secrets:vault?示例：
要明確指定所有詳細(xì)信息并使用?KV-V2?secret engine：
job:
secrets:
DATABASE_PASSWORD: # Store the path to the secret in this CI/CD variable
vault: # Translates to secret: `ops/data/production/db`, field: `password`
engine:
name: kv-v2
path: ops
path: production/db
field: password您可以縮短此語(yǔ)法。 使用簡(jiǎn)短的語(yǔ)法，engine:name?和?engine:path?都默認(rèn)為?kv-v2：
job:
secrets:
DATABASE_PASSWORD: # Store the path to the secret in this CI/CD variable
vault: production/db/password # Translates to secret: `kv-v2/data/production/db`, field: `password`要以簡(jiǎn)短的語(yǔ)法指定自定義 secret engine 路徑，請(qǐng)?zhí)砑右?@?開(kāi)頭的后綴：
job:
secrets:
DATABASE_PASSWORD: # Store the path to the secret in this CI/CD variable
vault: production/db/password@ops # Translates to secret: `ops/data/production/db`, field: `password`secrets:file
引入于 14.1 版本和 GitLab Runner 14.1.
使用?secrets:file?配置 secret 存儲(chǔ)為?file?或?variable?類(lèi)型 CI/CD 變量。
默認(rèn)情況下，secret 作為?file?類(lèi)型的 CI/CD 變量傳遞給作業(yè)。Secret 的值存儲(chǔ)在文件中，變量包含文件的路徑。
如果您的軟件不能使用?file?類(lèi)型的 CI/CD 變量，設(shè)置?file: false?將 secret 值直接存儲(chǔ)在變量中。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：true（默認(rèn)）或?false。
secrets:file?示例：
job:
secrets:
DATABASE_PASSWORD:
vault: production/db/password@ops
file: false額外細(xì)節(jié)：
-
file?關(guān)鍵字是 CI/CD 變量的設(shè)置，必須嵌套在 CI/CD 變量名稱(chēng)下，而不是在?vault?部分。
pages
使用?pages?定義一個(gè) GitLab Pages 作業(yè)，將靜態(tài)內(nèi)容上傳到極狐GitLab，然后將內(nèi)容發(fā)布為網(wǎng)站。
關(guān)鍵字類(lèi)型：作業(yè)名稱(chēng)。
pages?示例：
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH此示例將所有文件從項(xiàng)目的根目錄移動(dòng)到?public/?目錄。?.public?的解決方法是，cp?不會(huì)在無(wú)限循環(huán)中將?public/?復(fù)制到自身。
額外細(xì)節(jié)：
你必須：
- 將任何靜態(tài)內(nèi)容放在?
public/?目錄中。 - 定義?artifacts?和?
public/?目錄的路徑。
inherit
使用inherit:來(lái)控制默認(rèn)關(guān)鍵字和變量的繼承。
inherit:default
使用inherit:default來(lái)控制默認(rèn)關(guān)鍵字的繼承。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
-
true（默認(rèn)）或?false?啟用或禁用所有默認(rèn)關(guān)鍵字的繼承。 - 要繼承的特定默認(rèn)關(guān)鍵字列表。
inherit:default?示例：
default:
retry: 2
image: ruby:3.0
interruptible: true
job1:
script: echo "This job does not inherit any default keywords."
inherit:
default: false
job2:
script: echo "This job inherits only the two listed default keywords. It does not inherit 'interruptible'."
inherit:
default:
- retry
- image額外細(xì)節(jié)：
- 您還可以在一行中列出要繼承的默認(rèn)關(guān)鍵字：
default: [keyword1, keyword2]。
inherit:variables
使用inherit:variables來(lái)控制全局變量關(guān)鍵字的繼承。
關(guān)鍵字類(lèi)型：作業(yè)關(guān)鍵字。您只能將其用作作業(yè)的一部分。
可能的輸入：
-
true（默認(rèn)）或?false?來(lái)啟用或禁用所有全局變量的繼承。 - 要繼承的特定變量的列表。
inherit:variables?示例：
variables:
VARIABLE1: "This is variable 1"
VARIABLE2: "This is variable 2"
VARIABLE3: "This is variable 3"
job1:
script: echo "This job does not inherit any global variables."
inherit:
variables: false
job2:
script: echo "This job inherits only the two listed global variables. It does not inherit 'VARIABLE3'."
inherit:
variables:
- VARIABLE1
- VARIABLE2額外細(xì)節(jié)：
- 您還可以在一行中列出要繼承的全局變量：
variables: [VARIABLE1, VARIABLE2]
trigger:forward
- 引入于 14.9 版本，功能標(biāo)志名為?
ci_trigger_forward_variables。默認(rèn)禁用。- 在 SaaS 版和私有化部署版上啟用于 14.10 版本。
- 一般可用于 15.1 版本。功能標(biāo)志?
ci_trigger_forward_variables?刪除。
使用?trigger:forward?指定要轉(zhuǎn)發(fā)到下游流水線的內(nèi)容。您可以控制轉(zhuǎn)發(fā)到父子流水線和多項(xiàng)目流水線的內(nèi)容。
可能的輸入：
-
yaml_variables：true（默認(rèn)），或?false。當(dāng)為?true?時(shí)，觸發(fā)器作業(yè)中定義的變量被傳遞到下游流水線。 -
pipeline_variables:?true?或?false（默認(rèn)）。當(dāng)為?true?時(shí)，手動(dòng)流水線變量和計(jì)劃流水線變量被傳遞到下游流水線。
trigger:forward?示例：
手動(dòng)運(yùn)行此流水線，使用 CI/CD 變量?MYVAR = my value：
variables: # default variables for each job
VAR: value
# Default behavior:
# - VAR is passed to the child
# - MYVAR is not passed to the child
child1:
trigger:
include: .child-pipeline.yml
# Forward pipeline variables:
# - VAR is passed to the child
# - MYVAR is passed to the child
child2:
trigger:
include: .child-pipeline.yml
forward:
pipeline_variables: true
# Do not forward YAML variables:
# - VAR is not passed to the child
# - MYVAR is not passed to the child
child3:
trigger:
include: .child-pipeline.yml
forward:
yaml_variables: falsevariables
CI/CD 變量是傳遞給作業(yè)的可配置值。
使用?variables?創(chuàng)建自定義變量。
變量在?script、before_script?和?after_script?命令中始終可用。 您還可以在某些作業(yè)關(guān)鍵字中使用變量作為輸入。
關(guān)鍵字類(lèi)型：全局和工作關(guān)鍵字。您可以在全局級(jí)別使用它，也可以在作業(yè)級(jí)別使用它。
如果您在全局級(jí)別定義?variables，則在創(chuàng)建流水線時(shí)每個(gè)變量都會(huì)被復(fù)制到每個(gè)作業(yè)配置中。如果作業(yè)已經(jīng)定義了該變量，則作業(yè)級(jí)變量?jī)?yōu)先。
可能的輸入：變量名和值對(duì)：
- 名稱(chēng)只能使用數(shù)字、字母和下劃線 (
_)。 - 值必須是字符串。
variables?示例：
variables:
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH額外細(xì)節(jié)：
- 所有 YAML 定義的變量也設(shè)置為任何鏈接的 Docker 服務(wù)容器。
- YAML 定義的變量用于非敏感項(xiàng)目配置。將敏感信息存儲(chǔ)在受保護(hù)變量或 CI/CD secrets 中。
- 手動(dòng)流水線變量和計(jì)劃流水線變量默認(rèn)情況下不傳遞給下游流水線。使用?trigger:forward?將這些變量轉(zhuǎn)發(fā)到下游流水線。
variables:description
引入于 13.7 版本。
當(dāng)手動(dòng)運(yùn)行流水線時(shí)，使用?description?關(guān)鍵字定義預(yù)填的流水線級(jí)別（全局）變量。
必須與?value?一起使用，用于變量值。
關(guān)鍵字類(lèi)型：全局關(guān)鍵字。 當(dāng)您手動(dòng)運(yùn)行流水線時(shí)，您無(wú)法將作業(yè)級(jí)變量設(shè)置為預(yù)填充。
可能的輸入：一個(gè)字符串。
variables:description?示例：
variables:
DEPLOY_ENVIRONMENT:
value: "staging"
description: "The deployment target. Change this variable to 'canary' or 'production' if needed."廢棄的關(guān)鍵字
以下關(guān)鍵字已棄用。
全局定義的?types（已刪除）
WARNING:?types?已棄用，刪除于 15.0 版本。 使用?stages?代替。
作業(yè)定義的?type（已刪除）
WARNING:?type?已棄用，刪除于 15.0 版本。 使用?stage?代替。
全局定義的?image,?services,?cache,?before_script,?after_script
不推薦在全局范圍內(nèi)定義?image、services、cache、before_script?和?after_script?？赡軙?huì)從未來(lái)的版本中刪除支持。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-492195.html
使用?default:?代替。 例如：文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-492195.html
default:
image: ruby:3.0
services:
- docker:dind
cache:
paths: [vendor/]
before_script:
- bundle config set path vendor/bundle
- bundle install
after_script:
- rm -rf tmp/到了這里，關(guān)于gitlab-ci.yml 關(guān)鍵字參考 (FREE)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
