非推奨のキーワード

一部のCI/CDキーワードは非推奨であり、使用は推奨されなくなりました。

グローバル定義のimage、services、cache、before_script、after_script

image、services、cache、before_script、およびafter_scriptをグローバルに定義することは推奨されません。代わりにdefaultを使用してください。

例:

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/

only / except

onlyとexceptを使用すると、ジョブをパイプラインに追加するタイミングを制御できます。

• onlyを使用して、ジョブの実行タイミングを定義します。
• exceptを使用して、ジョブを実行does not（しない）タイミングを定義します。

only:refs / except:refs

only:refsキーワードとexcept:refsキーワードを使用して、ブランチ名またはパイプラインの種類に基づいて、ジョブをパイプラインに追加するタイミングを制御できます。

キーワードのタイプ: ジョブキーワード。ジョブの一部としてのみ使用できます。

サポートされている値: 次の要素を任意の数だけ含む配列:

• ブランチ名（mainやmy-feature-branchなど）。
• ブランチ名に一致する正規表現（/^feature-.*/など）。
• 次のキーワード:

  値	説明
  api	パイプラインAPIによってトリガーされたパイプライン。
  branches	パイプラインのGit参照がブランチである場合。
  chat	GitLab ChatOpsコマンドを使用して作成されたパイプライン。
  external	GitLab以外のCIサービスを使用する場合。
  external_pull_requests	GitHubで外部プルリクエストが作成または更新された場合（「外部プルリクエストのパイプライン」を参照）。
  merge_requests	マージリクエストの作成時または更新時に作成されるパイプラインの場合。マージリクエストパイプライン 、マージ結果パイプライン 、マージトレインを有効にします。
  pipelines	CI_JOB_TOKENを使用したAPI 、またはtriggerキーワードにより作成されたマルチプロジェクトパイプライン。
  pushes	git pushイベントによってトリガーされたパイプライン（ブランチとタグを含む）の場合。
  schedules	スケジュールされたパイプライン。
  tags	パイプラインのGit参照がタグの場合。
  triggers	トリガートークンを使用して作成されたパイプライン。
  web	GitLab UIで、プロジェクトのビルド > パイプラインセクションからパイプラインを新規作成を選択して作成されたパイプライン。

only:refsとexcept:refsの例:

job1:
  script: echo
  only:
    - main
    - /^issue-.*$/
    - merge_requests

job2:
  script: echo
  except:
    - main
    - /^stable-branch.*$/
    - schedules

補足情報:

• スケジュールされたパイプラインは特定のブランチで実行されるため、only: branchesで構成されたジョブもスケジュールされたパイプラインで実行されます。スケジュールされたパイプラインでonly: branchesを含むジョブが実行されないようにするには、except: schedulesを追加します。

• 他のキーワードなしで使用されるonlyまたはexceptは、only: refsまたはexcept: refsと同等です。たとえば、次の2つのジョブ構成の動作は同じです:

  job1:
    script: echo
    only:
      - branches
  
  job2:
    script: echo
    only:
      refs:
        - branches

• ジョブがonly、except、またはrulesのいずれも使用しない場合、デフォルトでは、onlyはbranchesとtagsに設定されます。

  たとえば、job1とjob2は同等です:

  job1:
    script: echo "test"
  
  job2:
    script: echo "test"
    only:
      - branches
      - tags

only:variables / except:variables

only:variablesまたはexcept:variablesキーワードを使用すると、CI/CD変数のステータスに基づいて、ジョブをパイプラインに追加するタイミングを制御できます。

キーワードのタイプ: ジョブキーワード。ジョブの一部としてのみ使用できます。

サポートされている値:

• CI/CD変数式の配列。

only:variablesの例

deploy:
  script: cap staging deploy
  only:
    variables:
      - $RELEASE == "staging"
      - $STAGING

only:changes / except:changes

changesキーワードをonlyとともに使用してジョブを実行するか、またはexceptとともに使用してGitプッシュイベントでファイルが変更された場合にジョブをスキップします。

パイプラインでchangesを次のrefとともに使用します:

• branches
• external_pull_requests
• merge_requests

キーワードのタイプ: ジョブキーワード。ジョブの一部としてのみ使用できます。

サポートされている値: 次の要素を任意の数だけ含む配列:

• ファイルのパス。
• 次のもののワイルドカードパス:
  • 単一のディレクトリ（例: path/to/directory/*）。
  • ディレクトリとそのすべてのサブディレクトリ（例: path/to/directory/**/*）。
• 同じ拡張子または複数の拡張子を持つすべてのファイルを対象とするワイルドカードglobパス（例: *.md、path/to/directory/*.{rb,py,sh}）。
• ルートディレクトリまたはすべてのディレクトリ内のファイルを対象とするワイルドカードパス（二重引用符で囲む）。例: "*.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"

補足情報:

• 一致するファイルのいずれかに変更がある場合、changesの解決結果はtrueになります（OR演算）。
• globパターンは、RubyのFile.fnmatchで、フラグFile::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOBを使用して解釈されます。
• branches、external_pull_requests、merge_requests以外のrefを使用すると、changesは特定のファイルが新しいか古いかを判別できず、常にtrueを返します。
• only: changesを他のrefとともに使用すると、ジョブは変更を無視して常に実行されます。
• except: changesを他のrefとともに使用すると、ジョブは変更を無視して決して実行されません。

関連トピック:

• only: changesを使用すると、予期せずにジョブまたはパイプラインが実行される可能性があります。

only:kubernetes / except:kubernetes

only:kubernetesまたはexcept:kubernetesを使用して、Kubernetesサービスがプロジェクトでアクティブな場合にジョブをパイプラインに追加するかどうかを制御します。

キーワードのタイプ: ジョブ固有。ジョブの一部としてのみ使用できます。

サポートされている値:

• kubernetes戦略は、activeキーワードのみを受け入れます。

only:kubernetesの例

deploy:
  only:
    kubernetes: active

この例では、deployジョブが実行されるのは、プロジェクト内でKubernetesサービスがアクティブになっている場合のみです。

GitLab Pagesのpublishキーワードとpagesジョブ名

GitLab Pagesのデプロイメントジョブに対するジョブレベルのpublishキーワードとpagesジョブ名は非推奨になりました。

pagesデプロイを制御するには、代わりにpagesキーワードとpages.publishキーワードを使用してください。

environment:kubernetes:namespaceとenvironment:kubernetes:flux_resource_path

environment:kubernetes:namespaceとenvironment:kubernetes:flux_resource_pathを使用してKubernetesダッシュボードの設定を構成できますが、kubernetesセクションの直下で使用すると非推奨になります。

キーワードのタイプ: ジョブキーワード。ジョブの一部としてのみ使用できます。

environment:kubernetes:namespaceとenvironment:kubernetes:flux_resource_pathの例:

deploy:
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      namespace: my-namespace
      flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release

environment:kubernetes:dashboard:namespaceとenvironment:kubernetes:dashboard:flux_resource_pathの例:

deploy:
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      dashboard:
        namespace: my-namespace
        flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release