介紹
建立并運作您的第一個 GitLab CI/CD 管道,在開始之前,請確定您擁有:
- GitLab 中您想要使用 CI/CD 的項目
- 項目的維護者或所有者角色
如果您沒有項目,可以在 https://gitlab.com 上免費建立一個公共項目
- 在存儲庫的根目錄下建立一個 .gitlab-ci.yml 檔案。該檔案是您定義 CI/CD 作業的地方
- 轉到Settings > CI/CD 并展開運作程式,隻要您至少有一個運作器處于活動狀态,旁邊有一個綠色圓圈,您就有一個運作器可以處理您的工作
示例
default:
image: node:16
windows_job:
only:
- master
tags:
- windows
script:
- echo Hello, %USERNAME%!
linux_job: tags:
- linux script:
- echo "Hello, $USER!"
tags 用于在不同的平台上運作作業,only 控制 master 分支送出觸發
關鍵字
關鍵字
default | 工作關鍵字的自定義預設值 # |
include | 從其他 YAML 檔案導入配置 # |
stages | 管道階段的名稱和順序 # |
variables | 為管道中的所有作業定義 CI/CD 變量 # |
workflow | 控制運作什麼類型的管道 # |
關鍵字
after_script | 覆寫一組在作業之後執行的指令 # |
allow_failure | 允許作業失敗。失敗的作業不會導緻管道失敗 # |
artifacts | 成功時附加到作業的檔案和目錄清單 # |
before_script | 覆寫在作業之前執行的一組指令 # |
cache | 應在後續運作之間緩存的檔案清單 # |
coverage | 給定作業的代碼覆寫率設定 # |
dast_configuration | 在作業級别使用 DAST 配置檔案中的配置 # |
dependencies | 通過提供要從中擷取工件的作業清單來限制将哪些工件傳遞給特定作業 # |
environment | 作業部署到的環境的名稱 # |
except | 控制何時不建立作業 # |
extends | 此作業繼承自的配置條目 # |
image | 使用 Docker 鏡像 # |
inherit | 選擇所有作業繼承的全局預設值 # |
interruptible | 定義作業是否可以在被較新的運作備援時取消 # |
needs | 在階段排序之前執行作業 # |
only | 控制何時建立作業 # |
pages | 上傳作業的結果以與 GitLab Pages 一起使用 # |
parallel | 應并行運作多少個作業執行個體 # |
release | 訓示運作器生成釋放對象 # |
resource_group | 限制作業并發 # |
retry | 發生故障時可以自動重試作業的時間和次數 # |
rules | 用于評估和确定作業的標明屬性以及是否建立的條件清單 # |
script | 由運作器執行的 Shell 腳本 # |
secrets | CI/CD 保密工作需要 # |
services | 使用 Docker 服務映像 # |
stage | 定義作業階段 # |
tags | 用于選擇跑步者的标簽清單 # |
timeout | 定義優先于項目範圍設定的自定義作業級逾時 # |
trigger | 定義下遊管道觸發器 # |
variables | 在作業級别定義作業變量 # |
when | 何時運作作業 # |
全局關鍵詞
- after_script
- artifacts
- before_script
- cache
- image
- interruptible
- retry
- services
- tags
- timeout
全局關鍵詞
default
default:
image: ruby:3.0
rspec:
script: bundle exec rspec
rspec 2.7:
image: ruby:2.7
script: bundle exec rspec
在此示例中,ruby:3.0 是管道中所有作業的預設圖像值。rspec 2.7 作業不使用預設值,因為它使用特定于作業的圖像部分覆寫了預設值
include
include:
- local: '/temp/.gitlab-ci-template.yml'
在 11.4 中移至 GitLab 免費版,使用 include 将外部 YAML 檔案包含在您的 CI/CD 配置中
include:local
include:
- local: '/temp/.gitlab-ci-template.yml'
使用 include:local 包含與 .gitlab-ci.yml 檔案位于同一存儲庫中的檔案
include:project
要在同一個 GitLab 執行個體上包含來自另一個私有項目的檔案,請使用 include:project 和 include:file
include:
- project: 'group/my-project'
file: '/temp/.gitlab-ci-template.yml'
- project: 'group/subgroup/my-project-2'
file:
- '/temp/.builds.yml'
- '/temp/.tests.yml'
您還可以指定一個 ref:
include:
- project: 'group/my-project'
ref: main # Git branch
file: '/templates/.gitlab-ci.yml'
- project: 'group/my-project'
ref: v1.0.0 # Git Tag
file: '/templates/.gitlab-ci.yml'
- project: 'group/my-project'
ref: 787123b # Git SHA
file: '/templates/.gitlab-ci.yml'
include:remote
include:
- remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
使用帶有完整 URL 的 include:remote 來包含來自不同位置的檔案
include:template
使用 include:template 來包含 .gitlab-ci.yml 模闆
# 檔案來自 GitLab 模闆集合
include:
- template: Auto-DevOps.gitlab-ci.yml
多個 include:template 檔案:
include:
- template: Android-Fastlane.gitlab-ci.yml
- template: Auto-DevOps.gitlab-ci.yml
stages
使用階段來定義包含作業組的階段。如果 .gitlab-ci.yml 檔案中未定義階段,則預設管道階段為:
- .pre
- build
- test
- deploy
- .post
stages:
- build
- test
- deploy
workflow
workflow:name
您可以在 workflow: 中使用 name 來定義管道的名稱
workflow:
name: '分支管道:$CI_COMMIT_BRANCH'
根據管道條件具有不同管道名稱的配置:
variables:
PIPELINE_NAME: '預設管道名稱'
workflow:
name: '$PIPELINE_NAME'
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
variables:
PIPELINE_NAME: 'MR pipeline: $CI_COMMIT_BRANCH'
- if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
variables:
PIPELINE_NAME: 'Ruby 3 pipeline'
workflow:rules:variables
您可以在 workflow:rules 中使用變量來定義特定管道條件的變量
variables:
DEPLOY_VARIABLE: "default-deploy"
workflow:
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables:
DEPLOY_VARIABLE: "deploy-production" # 覆寫全局定義的 DEPLOY_VARIABLE
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # 定義一個新變量
- when: always # 在其他情況下運作管道
job1:
variables:
DEPLOY_VARIABLE: "job1-default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # 覆寫定義的 DEPLOY_VARIABLE
DEPLOY_VARIABLE: "job1-deploy-production" # 在工作層面。
- when: on_success # 在其他情況下運作作業
script:
- echo "以 $DEPLOY_VARIABLE 作為參數運作腳本"
- echo "如果 $IS_A_FEATURE 存在則運作另一個腳本"
job2:
script:
- echo "以 $DEPLOY_VARIABLE 作為參數運作腳本"
- echo "如果 $IS_A_FEATURE 存在則運作另一個腳本"
workflow:rules
工作流(workflow)中的 rules 關鍵字類似于作業中定義的 rules,但控制是否建立整個管道
- rules: if
- rules: changes
- rules: exists
- when
- variables
workflow:
rules:
- if: $CI_COMMIT_TITLE =~ /-draft$/
when: never
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Job 關鍵詞
after_script
在每個作業(包括失敗的作業)之後運作的指令數組
job:
script:
- echo "示例腳本部分"
after_script:
- echo "在“script”部分完成後執行此指令"
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
environment: staging
allow_failure:exit_codes
控制何時允許作業失敗。對于任何列出的退出代碼,作業是 allow_failure: true,對于任何其他退出代碼,allow_failure false
test_job_1:
script:
- echo "退出代碼 1 的腳本。此作業失敗"
- exit 1
allow_failure:
exit_codes: 137
test_job_2:
script:
- echo "退出代碼 137 的腳本允許此作業失敗"
- exit 137
allow_failure:
exit_codes:
- 137
- 255
dast_configuration
stages:
- build
- dast
include:
- template: DAST.gitlab-ci.yml
dast:
dast_configuration:
site_profile: "Example Co"
scanner_profile: "Quick Passive Test"
指定要在 CI/CD 配置中使用的站點配置檔案和掃描器配置檔案。 兩個配置檔案必須首先在項目中建立。 作業的階段必須快
before_script
在每個作業的 script 指令之前運作,但在工件恢複之後運作
job:
before_script:
- echo "在任何“script:”指令之前執行此指令"
script:
- echo "“before_script”指令之後執行"
coverage
job1:
script: rspec
coverage: '/Code coverage: \d+\.\d+/'
使用自定義正規表達式的覆寫率來配置如何從作業輸出中提取代碼覆寫率
extends
.tests:
script: rake test
stage: test
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
only:
variables:
- $RSPEC
使用 extends 重用配置部分。 它是 YAML 錨點的替代品,并且更加靈活和可讀
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
environment: production
定義要從中擷取工件的作業清單。您還可以将作業設定為根本不下載下傳任何工件
inherit
使用 inherit 控制預設關鍵字和變量的繼承
inherit:default
使用 inherit:default 控制 default 關鍵字的繼承
default:
retry: 2
image: ruby:3.0
interruptible: true
job1:
script: echo "此作業不繼承任何預設關鍵字"
inherit:
default: false
job2:
script: echo "此作業僅繼承列出的兩個預設關鍵字。它不繼承“可中斷”"
inherit:
default:
- retry
- image
inherit:variables
使用 inherit:variables 控制全局變量關鍵字的繼承
variables:
VARIABLE1: "這是變量 1"
VARIABLE2: "這是變量 2"
VARIABLE3: "這是變量 3"
job1:
script: echo "該作業不繼承任何全局變量"
inherit:
variables: false
job2:
script: echo "此作業僅繼承列出的兩個全局變量。它不繼承“VARIABLE3”"
inherit:
variables:
- VARIABLE1
- VARIABLE2
interruptible
stages:
- stage1
- stage2
- stage3
step-1:
stage: stage1
script:
- echo "可以取消"
interruptible: true
step-2:
stage: stage2
script:
- echo "不能取消"
step-3:
stage: stage3
script:
- echo "因為第 2 步無法取消,是以此步驟永遠無法取消,即使它被設定為可中斷"
interruptible: true
如果在作業完成之前啟動較新的管道時應取消作業,則使用可中斷的
pages
pages:
stage: deploy
script:
- mkdir .public
- cp -r * .public
- mv .public public
artifacts:
paths:
- public
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
environment: production
使用頁面定義将靜态内容上傳到 GitLab 的 GitLab Pages 作業。然後将内容釋出為網站
parallel
test:
script: rspec
parallel: 5
使用 parallel 在單個管道中并行多次運作作業
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]
environment: $PROVIDER/$STACK
使用 parallel:matrix 在單個管道中并行多次運作作業,但每個作業執行個體具有不同的變量值
resource_group
deploy-to-production:
script: deploy
resource_group: production
建立一個資源組,以確定作業在同一項目的不同管道之間互斥
tags
job:
tags:
- ruby
- postgres
使用标簽從項目可用的所有運作器清單中選擇特定運作器
retry
test:
script: rspec
retry: 2
使用 retry 配置作業失敗時重試的次數。如果未定義,則預設為 0,并且作業不會重試
retry:when
test:
script: rspec
retry:
max: 2
when: runner_system_failure
使用 retry:when 和 retry:max 來重試特定失敗案例的作業。 retry:max 是最大重試次數,和retry一樣,可以是0、1、2
script
job1:
script: "bundle exec rspec"
job2:
script:
- uname -a
- bundle exec rspec
使用腳本指定運作器執行的指令
secrets
此關鍵字必須與 secrets:vault 一起使用
secrets:vault
使用 secrets:vault 指定 HashiCorp Vault 提供的秘密
job:
secrets:
# 将秘密的路徑存儲在此 CI/CD 變量中
DATABASE_PASSWORD:
# 轉換為秘密:`ops/data/production/db`
# 字段:`password`
vault:
engine:
name: kv-v2
path: ops
path: production/db
field: password
secrets:file
使用 secrets:file 将秘密配置為存儲為檔案或變量類型的 CI/CD 變量
job:
secrets:
DATABASE_PASSWORD:
vault: production/db/password@ops
file: false
timeout
build:
script: build.sh
timeout: 3 hours 30 minutes
test:
script: rspec
timeout: 3h 30m
為特定作業配置逾時。 如果作業運作時間超過逾時時間,則作業失敗
services
使用服務指定額外的 Docker 映像以在其中運作腳本
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
service:pull_policy
運作器用于擷取 Docker 映像的拉取政策
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]
stage
stages:
- build
- test
- deploy
job1:
stage: build
script:
- echo "這項工作編譯代碼"
job2:
stage: test
script:
- echo "此作業測試編譯後的代碼。它在建構階段完成時運作"
job3:
script:
- echo "這項工作也在測試階段運作"
job4:
stage: deploy
script:
- echo "此作業部署代碼。它在測試階段完成時運作"
environment: production
stage: .pre
stages:
- build
- test
job1:
stage: build
script:
- echo "該作業在建構階段運作"
first-job:
stage: .pre
script:
- echo "該作業在 .pre 階段運作,在所有其他階段之前"
job2:
stage: test
script:
- echo "該作業在測試階段運作"
stage: .post
stages:
- build
- test
job1:
stage: build
script:
- echo "該作業在建構階段運作"
last-job:
stage: .post
script:
- echo "該作業在 .post 階段運作,在所有其他階段之後"
job2:
stage: test
script:
- echo "該作業在測試階段運作"
trigger
聲明一個作業是一個“觸發作業”
trigger-multi-project-pipeline:
trigger: my-group/my-project
trigger:include
trigger-child-pipeline:
trigger:
include: path/to/child-pipeline.gitlab-ci.yml
聲明作業是啟動子管道的“觸發器作業”
trigger:project
trigger-multi-project-pipeline:
trigger:
project: my-group/my-project
聲明作業是啟動多項目管道的“觸發器作業”
trigger:strategy
trigger-multi-project-pipeline:
trigger:
project: my-group/my-project
branch: development
強制觸發作業等待下遊管道完成後再标記為成功
trigger:forward
variables: # 每個作業的預設變量
VAR: value
# 預設行為:
# - VAR 傳遞給孩子
# - MYVAR 沒有傳遞給孩子
child1:
trigger:
include: .child-pipeline.yml
# 轉發管道變量:
# - VAR 傳遞給孩子
# - MYVAR 傳遞給孩子
child2:
trigger:
include: .child-pipeline.yml
forward:
pipeline_variables: true
# 不要轉發 YAML 變量:
# - VAR 不會傳遞給孩子
# - MYVAR 沒有傳遞給孩子
child3:
trigger:
include: .child-pipeline.yml
forward:
yaml_variables: false
variables
CI/CD 變量是傳遞給作業的可配置值。使用變量建立自定義變量
variables:
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
environment: production
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
environment: production
variables:description
variables:
DEPLOY_ENVIRONMENT:
description: "部署目标。 如果需要,将此變量更改為“canary”或“production”"
value: "staging"
variables:expand
variables:
VAR1: value1
VAR2: value2 $VAR1
VAR3:
value: value3 $VAR1
expand: false
使用 expand 關鍵字将變量配置為可擴充或不可擴充
when
使用 when 配置作業運作的條件。如果未在作業中定義,則預設值為 when:on_success
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
environment: production
cleanup_job:
stage: cleanup
script:
- cleanup after jobs
when: always
on_success(default) | 僅當早期階段的所有作業都成功或具有 allow_failure: true 時才運作該作業 |
manual | 僅在手動觸發時運作作業 |
always | 無論早期階段的作業狀态如何,都運作作業。也可以用在 workflow:rules 中 |
on_failure | 僅當早期階段的至少一項作業失敗時才運作該作業 |
delayed | 将作業的執行延遲指定的持續時間 |
never | 不要運作作業。隻能在規則rules部分或工作流中使用:workflow: rules |
artifacts
使用工件指定要将哪些檔案另存為作業 artifacts。作業 artifacts 是作業成功、失敗或始終附加到作業的檔案和目錄的清單
artifacts:paths
路徑是相對于項目目錄($CI_PROJECT_DIR)的,不能直接連結到項目目錄之外
job:
artifacts:
paths:
- binaries/
- .config
artifacts:exclude
防止将檔案添加到 artifacts 存檔中
artifacts:
paths:
- binaries/
exclude:
- binaries/**/*.o
artifacts:expire_in
指定作業 artifacts 在它們過期和被删除之前存儲多長時間
job:
artifacts:
expire_in: 1 week
- '42'
- 42 seconds
- 3 mins 4 sec
- 2 hrs 20 min
- 2h20min
- 6 mos 1 day
- 47 yrs 6 mos and 4d
- 3 weeks and 2 days
- never
artifacts:expose_as
使用 artifacts:expose_as 關鍵字在合并請求 UI 中公開作業 artifacts
test:
script: ["echo 'test' > file.txt"]
artifacts:
expose_as: 'artifact 1'
paths: ['file.txt']
artifacts:name
定義建立的 artifacts 存檔的名稱。您可以為每個存檔指定一個唯一的名稱
job:
artifacts:
name: "job1-artifacts-file"
paths:
- binaries/
artifacts:public
确定作業工件是否應該公開可用
job:
artifacts:
public: false
artifacts:reports
收集作業中包含的模闆生成的 artifacts
rspec:
stage: test
script:
- bundle install
- rspec --format RspecJunitFormatter --out rspec.xml
artifacts:
reports:
junit: rspec.xml
artifacts:untracked
将所有 Git 未跟蹤檔案添加為 artifacts(連同在 artifacts:paths 中定義的路徑)
job:
artifacts:
untracked: true
artifacts:when
作業失敗或盡管失敗時上傳 artifacts
job:
artifacts:
when: on_failure
cache
cache:paths
rspec:
script:
- echo "此作業使用緩存"
cache:
key: binaries-cache
paths:
- binaries/*.apk
- .config
關鍵字來選擇要緩存的檔案或目錄
cache:key
為每個緩存提供唯一的辨別鍵。 使用相同緩存鍵的所有作業都使用相同的緩存,包括在不同的管道中
cache-job:
script:
- echo "此作業使用緩存"
cache:
key: binaries-cache-$CI_COMMIT_REF_SLUG
paths:
- binaries/
cache:key:files
cache-job:
script:
- echo "此作業使用緩存"
cache:
key:
files:
- Gemfile.lock
- package.json
paths:
- vendor/ruby
- node_modules
當一個或兩個特定檔案更改時,使用 cache:key:files 關鍵字生成新密鑰
cache:key:prefix
rspec:
script:
- echo "此 rspec 作業使用緩存"
cache:
key:
files:
- Gemfile.lock
prefix: $CI_JOB_NAME
paths:
- vendor/ruby
使用 cache:key:prefix 将字首與為 cache:key:files 計算的 SHA 結合起來
cache:untracked
rspec:
script: test
cache:
untracked: true
paths:
- binaries/
使用 untracked: true 緩存 Git 存儲庫中所有未跟蹤的檔案
cache:when
rspec:
script: rspec
cache:
paths:
- rspec/
when: 'always'
使用 cache:when 根據作業的狀态定義何時儲存緩存
on_succes(預設) | 僅當作業成功時才儲存緩存 |
on_failure | 僅在作業失敗時才儲存緩存 |
always | 始終儲存緩存 |
cache:policy
prepare-dependencies-job:
stage: build
cache:
key: gems
paths:
- vendor/bundle
policy: push
script:
- echo "此作業僅下載下傳依賴項并建構緩存"
- echo "正在下載下傳依賴..."
faster-test-job:
stage: test
cache:
key: gems
paths:
- vendor/bundle
policy: pull
script:
- echo "此作業腳本使用緩存,但不更新它"
- echo "運作測試..."
要更改緩存的上傳和下載下傳行為,請使用 cache:policy 關鍵字
environment
environment:name
deploy to production:
stage: deploy
script: git push production HEAD:main
environment:
name: production
為環境設定名稱
environment:url
deploy to production:
stage: deploy
script: git push production HEAD:main
environment:
name: production
url: https://prod.example.com
為環境設定 URL
environment:on_stop
關閉(停止)環境可以通過在環境下定義的 on_stop 關鍵字來實作。 它聲明運作以關閉環境的不同作業
environment:action
stop_review_app:
stage: deploy
variables:
GIT_STRATEGY: none
script: make delete-app
when: manual
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
start 預設值 | 訓示作業啟動環境。在作業開始後建立的 |
prepare | 表示作業隻是準備環境。它不會觸發部署 |
stop | 訓示作業停止部署 |
verify | 訓示作業僅驗證環境。它不會觸發部署 |
access | 訓示作業僅通路環境。它不會觸發部署 |
environment:auto_stop_in
review_app:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_SLUG
auto_stop_in: 1 day
- 168 hours
- 7 days
- one week
- never
auto_stop_in 關鍵字指定環境的生命周期。 當環境到期時,GitLab 會自動停止它
environment:kubernetes
deploy:
stage: deploy
script: make deploy-app
environment:
name: production
kubernetes:
namespace: production
使用 kubernetes 關鍵字将部署配置到與您的項目關聯的 Kubernetes 叢集
environment:deployment_tier
deploy:
script: echo
environment:
name: customer-portal
deployment_tier: production
- production
- staging
- testing
- development
- other
動态 environment
deploy as review app:
stage: deploy
script: make deploy
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_ENVIRONMENT_SLUG.example.com/
image
image:name
image:
name: "registry.example.com/my/image:latest"
作業運作所在的 Docker 鏡像的名稱。類似于它自己使用的鏡像
image:entrypoint
image:
name: super/sql:experimental
entrypoint: [""]
作為容器入口點執行的指令或腳本
image:pull_policy
job1:
script: echo "單一拉動政策"
image:
name: ruby:3.0
pull_policy: if-not-present
job2:
script: echo "多重拉動政策"
image:
name: ruby:3.0
pull_policy: [always, if-not-present]
運作器用于擷取 Docker 映像的拉取政策
needs
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
needs:project
使用 needs:project 從其他管道中的最多五個作業下載下傳工件。工件是從指定參考的最新成功管道下載下傳的。要指定多個作業,請将每個作業作為單獨的數組項添加到 needs 關鍵字下
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
needs:pipeline:job
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
子管道可以從其父管道中的作業或同一父子管道層次結構中的另一個子管道下載下傳工件
needs:optional
要需要管道中有時不存在的作業,請将 optional: true 添加到需求配置中。如果未定義,則可選:預設為 false
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
environment: production
review-job:
stage: deploy
needs:
- job: test-job2
optional: true
environment: review
needs:pipeline
您可以使用 needs:pipeline 關鍵字将管道狀态從上遊管道鏡像到橋接作業
upstream_bridge:
stage: test
needs:
pipeline: other/project
only / except
only:refs / except:refs
job1:
script: echo
only:
- main
- /^issue-.*$/
- merge_requests
job2:
script: echo
except:
- main
- /^stable-branch.*$/
- schedules
使用 only:refs 和 except:refs 關鍵字來控制何時根據分支名稱或管道類型将作業添加到管道
only:variables / except:variables
deploy:
script: cap staging deploy
only:
variables:
- $RELEASE == "staging"
- $STAGING
根據 CI/CD 變量的狀态,使用 only:variables 或 except:variables 關鍵字來控制何時将作業添加到管道
only:changes / except: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"
當 Git 推送事件修改檔案時,使用 changes 關鍵字僅運作作業,或使用 except 跳過作業
only:kubernetes / except:kubernetes
deploy:
only:
kubernetes: active
使用 only:kubernetes 或 except:kubernetes 來控制當 Kubernetes 服務在項目中處于活動狀态時是否将作業添加到管道中
release
release 參考
release:tag_name | 釋出的 Git 标簽 |
release:tag_message | 指定的消息進行注釋 |
release:name | 釋出名稱 |
release:description | 版本的較長的描述 |
release:ref | 釋出的 ref |
release:milestones | 每個裡程碑的标題 |
release:released_at | 釋出準備就緒的日期和時間 |
release:tag_name
job:
script: echo "為新标簽運作釋出作業"
release:
tag_name: $CI_COMMIT_TAG
description: 'Release description'
rules:
- if: $CI_COMMIT_TAG
必需的。釋出的 Git 标簽
release:tag_message
release_job:
stage: release
release:
tag_name: $CI_COMMIT_TAG
description: 'Release description'
tag_message: 'Annotated tag message'
如果标簽不存在,則新建立的标簽将使用 tag_message 指定的消息進行注釋
release:name
release_job:
stage: release
release:
name: 'Release $CI_COMMIT_TAG'
釋出名稱。如果省略,它會填充 release:tag_name 的值
release:description
job:
release:
tag_name: ${MAJOR}_${MINOR}_${REVISION}
description: './path/to/CHANGELOG.md'
版本的較長的描述
release:ref
釋出的 ref,如果釋出:tag_name 尚不存在
release:milestones
與版本關聯的每個裡程碑的标題
release:released_at
released_at: '2021-03-15T08:00:00Z'
釋出準備就緒的日期和時間
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' # 可選的
link_type: 'other' # 可選的
使用 release:assets:links 在釋出中包含資産連結
rules
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
使用 rules:if 子句指定何時将作業添加到管道
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
使用 rules:changes 通過檢查對特定檔案的更改來指定何時将作業添加到管道
rules:changes:paths
docker-build-1:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
- Dockerfile
docker-build-2:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
paths:
- Dockerfile
使用 rules:changes 指定僅在更改特定檔案時将作業添加到管道,并使用 rules:changes:paths 指定檔案
rules:changes:compare_to
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
paths:
- Dockerfile
compare_to: 'refs/heads/branch1'
使用 rules:changes:compare_to 指定要比較哪個 ref 來比較 rules:changes:paths 下列出的檔案的更改
rules:exists
job:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- exists:
- Dockerfile
當存儲庫中存在某些檔案時,使用 exists 運作作業
rules:allow_failure
job:
script: echo "Hello, Rules!"
rules:
- if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
when: manual
allow_failure: true
在規則中使用 allow_failure: true 允許作業失敗而不停止管道
rules:variables
job:
variables:
DEPLOY_VARIABLE: "default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # 覆寫定義的 DEPLOY_VARIABLE
DEPLOY_VARIABLE: "deploy-production" # 在工作層面
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # 定義一個新變量
script:
- echo "以 $DEPLOY_VARIABLE 作為參數運作腳本"
- echo "如果 $IS_A_FEATURE 存在則運作另一個腳本"
在規則中使用變量來為特定條件定義變量
doc https://docs.gitlab.com/ee/ci/yaml/