天天看點

項目中GitLab 使用 CI/CD 常用指令(備忘查詢)

作者:區塊軟體開發
項目中GitLab 使用 CI/CD 常用指令(備忘查詢)

介紹

建立并運作您的第一個 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/

繼續閱讀