GitLab CI/CDのworkflowキーワード

.gitlab-ci.ymlファイルでworkflowキーワードを使用して、パイプラインがいつ作成されるかを制御します。

workflowキーワードは、ジョブの前に評価されます。たとえば、ジョブがタグに対して実行するように設定されていても、ワークフローでタグパイプラインを禁止している場合、ジョブは実行されません。

workflow:rulesの一般的なif句

workflow: rulesのif句の例:

詳細については、rulesの一般的なif句を参照してください。

workflow: rulesの例

次の例では、以下が実行されます:

• すべてのpushイベント（ブランチへの変更と新しいタグ）に対してパイプラインが実行されます。
• コミットメッセージが-draftで終わるプッシュイベントのパイプラインは、when: neverに設定されているため実行されません。
• スケジュールまたはマージリクエストのパイプラインも、trueと評価されるルールが存在しないため実行されません。

workflow:
  rules:
    - if: $CI_COMMIT_MESSAGE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

この例ではルールが厳密に定義されており、条件に該当しない場合はパイプラインはnot（実行されません）。

別の方法として、すべてのルールをwhen: neverにして、最後にwhen: alwaysルールを指定することもできます。when: neverルールに一致するパイプラインは実行されません。それ以外のすべてのパイプラインタイプは実行されます。次に例を示します:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always

この例では、スケジュールやpush（ブランチとタグ）に対するパイプラインは実行されません。最後のwhen: alwaysルールは、マージリクエストパイプラインincluding（を含む）その他すべてのパイプラインタイプを実行します。

ブランチパイプラインとマージリクエストパイプラインを切り替える

マージリクエストの作成後に、パイプラインをブランチパイプラインからマージリクエストパイプラインに切り替えるには、.gitlab-ci.ymlファイルにworkflow: rulesセクションを追加します。

両方のパイプラインタイプを同時に使用すると、重複するパイプラインが同時に実行される可能性があります。パイプラインの重複を防ぐには、CI_OPEN_MERGE_REQUESTS変数を使用します。

ブランチパイプラインとマージリクエストパイプラインのみを実行し、それ以外の場合にはパイプラインを実行しないプロジェクトの例を次に示します。この例は、次のように動作します:

• ブランチに対してマージリクエストがオープンされていない場合は、ブランチパイプラインを実行する。
• ブランチに対してマージリクエストがオープンされている場合は、マージリクエストパイプラインを実行する。

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH

GitLabがトリガーしようとするパイプラインタイプに応じて、次のように動作します:

• マージリクエストパイプラインの場合、パイプラインを開始します。たとえば、マージリクエストパイプラインは、関連するマージリクエストがオープンされているブランチへのプッシュによってトリガーされることがあります。
• ブランチパイプラインの場合、そのブランチに対してマージリクエストがオープンされていれば、ブランチパイプラインは実行されません。たとえば、ブランチパイプラインは、ブランチへの変更、APIコール、スケジュール済みパイプラインなどによってトリガーされることがあります。
• ブランチパイプラインの場合、そのブランチに対してマージリクエストがオープンされていなければ、ブランチパイプラインが実行されます。

既存のworkflowセクションにルールを追加して、マージリクエストが作成されたときにブランチパイプラインからマージリクエストパイプラインに切り替えることもできます。

このルールをworkflowセクションの先頭に追加し、その後に既存の他のルールを続けます:

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - # Previously defined workflow rules here

ブランチで実行されるトリガーされたパイプラインには$CI_COMMIT_BRANCHが設定されており、同様のルールによってブロックされる可能性があります。トリガーされたパイプラインのソースはtriggerまたはpipelineであるため、&& $CI_PIPELINE_SOURCE == "push"を条件に追加することで、トリガーされたパイプラインがこのルールによってブロックされるのを防ぐことができます。

マージリクエストパイプラインを使用したGit Flow

workflow: rulesは、マージリクエストパイプラインで使用できます。これらのルールを使用すると、フィーチャーブランチでマージリクエストパイプラインの機能を活用しながら、長期的なブランチを維持してソフトウェアの複数のバージョンをサポートできます。

たとえば、マージリクエスト、タグ、保護ブランチに対してのみパイプラインを実行するには、次のようにします:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_REF_PROTECTED == "true"

この例では、長期的なブランチが保護されていることを前提としています。

ドラフトマージリクエストのパイプラインをスキップする

workflow: rulesを使用して、ドラフトマージリクエストのパイプラインをスキップできます。これらのルールを使用すると、開発が完了するまでコンピューティング時間の消費を回避できます。

たとえば、次のルールは、タイトルに[Draft]、(Draft)、またはDraft:が含まれるマージリクエストのCIビルドを無効にします:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TITLE =~ /^(\[Draft\]|\(Draft\)|Draft:)/
      when: never

stages:
  - build

build-job:
  stage: build
  script:
    - echo "Testing"

トラブルシューティング

Checking pipeline status.メッセージが表示されてマージリクエストがスタックする

マージリクエストにChecking pipeline status.と表示され、このメッセージが消えない（「スピナー」が回転し続ける）場合、workflow:rulesが原因である可能性があります。この問題は、プロジェクトでパイプラインが完了している条件が有効になっているにもかかわらず、workflow:rulesによってマージリクエストのパイプラインの実行が妨げられている場合に発生することがあります。

たとえば、次のワークフローではパイプラインを実行できないため、マージリクエストをマージできません:

workflow:
  rules:
    - changes:
        - .gitlab/**/**.md
      when: never