GitHub Actions でワークフローを作成する際、特定の条件でジョブやステップを実行したい場面は多いですよね。 本記事では、GitHub Actions の条件式（if 条件）について、実践的な使い方を徹底解説します。 contains や startsWith などの関数、always や success といったステータスチェック関数まで、使える条件式を網羅的にご紹介しますね。

早見表：GitHub Actions 条件式一覧

#	条件式	説明	使用例
1	if: success()	前のステップが成功した場合に実行	通常のステップ実行
2	if: failure()	前のステップが失敗した場合に実行	エラー通知、ロールバック
3	if: always()	前のステップの結果に関わらず常に実行	クリーンアップ、ログ保存
4	if: cancelled()	ワークフローがキャンセルされた場合に実行	キャンセル時の後処理
5	if: contains(値, '検索文字列')	値に特定の文字列が含まれる場合に実行	ブランチ名、コミットメッセージの判定
6	if: startsWith(値, '接頭辞')	値が特定の文字列で始まる場合に実行	feature/ ブランチの判定
7	if: endsWith(値, '接尾辞')	値が特定の文字列で終わる場合に実行	ファイル拡張子の判定
8	if: github.event_name == 'push'	特定のイベントで実行	push、pull_request の判定
9	if: github.ref == 'refs​/​heads​/​main'	特定のブランチで実行	main ブランチでのみ実行
10	if: runner.os == 'Linux'	特定の OS で実行	OS 依存の処理
11	if: env.DEBUG == 'true'	環境変数による条件分岐	デバッグモードの切り替え
12	if: steps.ステップID.outputs.結果 == '値'	前ステップの出力による条件分岐	テスト結果に応じた処理

背景

GitHub Actions は、CI/CD パイプラインを構築するための強力なツールです。 ワークフローを作成する際、すべてのステップを常に実行するわけではなく、特定の条件下でのみ実行したい場面が頻繁にありますね。

たとえば、以下のような要件があります。

• main ブランチへのプッシュ時のみデプロイを実行したい
• テストが失敗したときだけ通知を送りたい
• feature/ で始まるブランチでは特定の処理をスキップしたい
• 前のステップの結果に応じて次の処理を変えたい

こうした柔軟なワークフロー制御を実現するために、GitHub Actions には強力な条件式の仕組みが用意されています。

以下の図は、条件式がワークフローのどの段階で評価されるかを示したものです。

mermaidCopy codeflowchart TB
  trigger["ワークフロー<br/>トリガー発火"] --> eval["条件式 if の<br/>評価"]
  eval -->|"true"| exec["ステップまたは<br/>ジョブを実行"]
  eval -->|"false"| skip["スキップ"]
  exec --> next["次のステップへ"]
  skip --> next
  next --> check{"他に実行する<br/>ステップがある?"}
  check -->|"はい"| eval
  check -->|"いいえ"| done["ワークフロー完了"]

図で理解できる要点

• 条件式は各ステップ・ジョブの実行前に評価される
• true なら実行、false ならスキップされる
• スキップされたステップも後続の処理には影響しない

課題

GitHub Actions で条件式を使う際には、以下のような課題に直面することがあります。

複雑な条件式の構文

GitHub Actions の条件式は、独自の構文と関数を使用します。 一般的なプログラミング言語とは異なる記法のため、初めて使う際には戸惑うことが多いでしょう。

ステータスチェック関数の理解不足

success()、failure()、always() などのステータスチェック関数は、前のステップの結果に応じた処理を行うために重要です。 しかし、これらの関数のデフォルト動作や使い分けが明確でないと、意図しない動作になることがありますね。

コンテキスト変数の活用方法

github.ref、github.event_name、runner.os といったコンテキスト変数は、ワークフローの実行環境に関する情報を提供します。 これらをどのように条件式で活用するかを理解しないと、柔軟なワークフローを構築できません。

以下の図は、条件式を使わない場合と使う場合の違いを示しています。

mermaidCopy codeflowchart LR
  subgraph without["条件式なし"]
    step1["ステップ1"] --> step2["ステップ2"]
    step2 --> step3["ステップ3"]
    step3 --> step4["ステップ4"]
  end

  subgraph with["条件式あり"]
    stepA["ステップ1"] --> evalB{"条件式B"}
    evalB -->|"true"| stepB["ステップ2"]
    evalB -->|"false"| evalC{"条件式C"}
    stepB --> evalC
    evalC -->|"true"| stepC["ステップ3"]
    evalC -->|"false"| stepD["ステップ4"]
    stepC --> stepD
  end

図で理解できる要点

• 条件式なしでは全ステップが順次実行される
• 条件式ありでは、条件に応じて実行経路が分岐する
• より柔軟で効率的なワークフローが実現できる

解決策

GitHub Actions の条件式を使いこなすことで、これらの課題を解決できます。 ここでは、代表的な条件式と関数について、具体的な使い方を解説しますね。

if 条件の基本構文

GitHub Actions では、if キーワードを使ってジョブやステップに条件を設定します。

yamlCopy code- name: ステップ名
  if: 条件式
  run: コマンド

条件式は ${{ }} で囲む必要はありません。 GitHub Actions が自動的に式として評価してくれます。

ステータスチェック関数

success() - 前のステップが成功した場合

デフォルトでは、各ステップは暗黙的に if: success() が設定されています。 前のステップが成功した場合のみ実行されますね。

yamlCopy code- name: テスト実行
  run: npm test

- name: テスト成功時のみ実行
  if: success()
  run: echo "テストが成功しました"

failure() - 前のステップが失敗した場合

前のステップが失敗したときのみ実行したい場合に使用します。 エラー通知やロールバック処理に便利です。

yamlCopy code- name: テスト実行
  run: npm test

- name: テスト失敗時の通知
  if: failure()
  run: echo "テストが失敗しました" && exit 0

ポイント: failure() を使ったステップ自体は成功扱いにするため、exit 0 を使うことが多いです。

always() - 常に実行

前のステップの成否に関わらず、常に実行したい場合に使用します。 クリーンアップ処理やログの保存に最適ですね。

yamlCopy code- name: テスト実行
  run: npm test

- name: 後処理（常に実行）
  if: always()
  run: |
    echo "ワークフロー完了"
    npm run cleanup

cancelled() - ワークフローがキャンセルされた場合

ワークフローがキャンセルされたときに実行されます。 キャンセル時の後処理に使用できますね。

yamlCopy code- name: キャンセル時の処理
  if: cancelled()
  run: echo "ワークフローがキャンセルされました"

以下の図は、各ステータスチェック関数の動作を示しています。

mermaidCopy codestateDiagram-v2
  [*] --> StepExecuting: ステップ実行開始
  StepExecuting --> Success: 成功
  StepExecuting --> Failure: 失敗
  StepExecuting --> Cancelled: キャンセル

  Success --> NextStep_success: success() 条件
  Failure --> NextStep_failure: failure() 条件
  Cancelled --> NextStep_cancelled: cancelled() 条件
  Success --> NextStep_always: always() 条件
  Failure --> NextStep_always
  Cancelled --> NextStep_always

  NextStep_success --> [*]
  NextStep_failure --> [*]
  NextStep_cancelled --> [*]
  NextStep_always --> [*]

図で理解できる要点

• ステップの実行結果は 3 つの状態（成功、失敗、キャンセル）に分かれる
• success() は成功時のみ、failure() は失敗時のみ実行される
• always() はすべての状態で実行される

文字列検索関数

contains() - 文字列が含まれるかチェック

contains(検索対象, '検索文字列') は、検索対象に特定の文字列が含まれているかを判定します。

yamlCopy code- name: feature ブランチを含む場合に実行
  if: contains(github.ref, 'feature')
  run: echo "feature ブランチです"

コミットメッセージに特定のキーワードが含まれる場合の条件分岐も可能です。

yamlCopy code- name: コミットメッセージに [skip ci] がない場合に実行
  if: contains(github.event.head_commit.message, '[skip ci]') == false
  run: npm test

startsWith() - 文字列が特定の接頭辞で始まるかチェック

startsWith(検索対象, '接頭辞') は、文字列が特定の接頭辞で始まるかを判定します。

yamlCopy code- name: feature/ ブランチのみ実行
  if: startsWith(github.ref, 'refs/heads/feature/')
  run: echo "feature ブランチです"

複数の接頭辞を OR 条件で組み合わせることもできます。

yamlCopy code- name: feature/ または bugfix/ ブランチで実行
  if: |
    startsWith(github.ref, 'refs/heads/feature/') ||
    startsWith(github.ref, 'refs/heads/bugfix/')
  run: echo "開発ブランチです"

endsWith() - 文字列が特定の接尾辞で終わるかチェック

endsWith(検索対象, '接尾辞') は、文字列が特定の接尾辞で終わるかを判定します。

yamlCopy code- name: .js ファイルが変更された場合に実行
  if: endsWith(github.event.head_commit.modified[0], '.js')
  run: npm run lint:js

コンテキスト変数を使った条件式

github.event_name - イベントタイプによる条件分岐

GitHub Actions は、push、pull_request、schedule など、さまざまなイベントで起動できます。 github.event_name を使って、イベントタイプに応じた処理を行えますね。

yamlCopy code- name: push イベント時のみ実行
  if: github.event_name == 'push'
  run: echo "push イベントです"

yamlCopy code- name: pull_request イベント時のみ実行
  if: github.event_name == 'pull_request'
  run: npm run test:pr

github.ref - ブランチ名による条件分岐

github.ref は、現在のブランチやタグの参照を表します。 特定のブランチでのみ実行したい処理に使用できますね。

yamlCopy code- name: main ブランチのみデプロイ
  if: github.ref == 'refs/heads/main'
  run: npm run deploy

yamlCopy code- name: develop ブランチのみ実行
  if: github.ref == 'refs/heads/develop'
  run: npm run deploy:staging

runner.os - OS による条件分岐

マルチ OS 環境でワークフローを実行する場合、runner.os を使って OS ごとに異なる処理を実行できます。

yamlCopy code- name: Linux のみ実行
  if: runner.os == 'Linux'
  run: apt-get update

yamlCopy code- name: macOS のみ実行
  if: runner.os == 'macOS'
  run: brew update

yamlCopy code- name: Windows のみ実行
  if: runner.os == 'Windows'
  run: choco upgrade

env - 環境変数による条件分岐

環境変数を使った条件分岐も可能です。 デバッグモードや環境ごとの設定に便利ですね。

yamlCopy codeenv:
  DEBUG: 'true'

steps:
  - name: デバッグモード時のみ実行
    if: env.DEBUG == 'true'
    run: echo "デバッグモードが有効です"

yamlCopy codeenv:
  ENVIRONMENT: 'production'

steps:
  - name: 本番環境のみ実行
    if: env.ENVIRONMENT == 'production'
    run: npm run deploy:prod

steps.ステップ ID.outputs - 前ステップの出力による条件分岐

前のステップの出力結果を使って、次のステップの実行を制御できます。

yamlCopy code- name: テスト実行
  id: test_step
  run: |
    npm test
    echo "result=success" >> $GITHUB_OUTPUT

yamlCopy code- name: テスト結果による条件分岐
  if: steps.test_step.outputs.result == 'success'
  run: echo "テストが成功しました"

論理演算子の使用

複数の条件を組み合わせる場合、論理演算子を使用します。

AND 条件 (&&)

yamlCopy code- name: main ブランチかつ push イベント時に実行
  if: |
    github.ref == 'refs/heads/main' &&
    github.event_name == 'push'
  run: npm run deploy

OR 条件 (||)

yamlCopy code- name: main または develop ブランチで実行
  if: |
    github.ref == 'refs/heads/main' ||
    github.ref == 'refs/heads/develop'
  run: npm run build

NOT 条件 (!)

yamlCopy code- name: main ブランチ以外で実行
  if: github.ref != 'refs/heads/main'
  run: npm run test

yamlCopy code- name: push イベント以外で実行
  if: "!contains(github.event_name, 'push')"
  run: echo "push 以外のイベントです"

ジョブレベルでの条件式

条件式は、ステップだけでなくジョブレベルでも使用できます。

yamlCopy codejobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm test

yamlCopy codedeploy:
  runs-on: ubuntu-latest
  needs: test
  if: github.ref == 'refs/heads/main'
  steps:
    - uses: actions/checkout@v3
    - run: npm run deploy

この例では、deploy ジョブは test ジョブが成功し、かつ main ブランチの場合のみ実行されます。

以下の図は、条件式を使った実践的なワークフローの流れを示しています。

mermaidCopy codeflowchart TD
  start["ワークフロー開始"] --> checkout["コードチェックアウト"]
  checkout --> test["テスト実行"]

  test --> test_result{"テスト結果"}
  test_result -->|"成功"| build["ビルド実行"]
  test_result -->|"失敗"| notify_fail["失敗通知<br/>if: failure()"]

  build --> branch_check{"ブランチ確認<br/>if: github.ref"}
  branch_check -->|"main"| deploy_prod["本番デプロイ"]
  branch_check -->|"develop"| deploy_stg["ステージングデプロイ"]
  branch_check -->|"その他"| skip_deploy["デプロイスキップ"]

  deploy_prod --> cleanup["クリーンアップ<br/>if: always()"]
  deploy_stg --> cleanup
  skip_deploy --> cleanup
  notify_fail --> cleanup

  cleanup --> end_workflow["ワークフロー完了"]

図で理解できる要点

• テスト結果に応じて後続処理が分岐する
• ブランチごとに異なるデプロイ先を設定できる
• クリーンアップは常に実行され、確実に後処理が行われる

具体例

ここでは、実践的なユースケースごとに、条件式を使ったワークフローの例を紹介します。

例 1：ブランチごとの自動デプロイ

main ブランチへの push 時のみ本番環境にデプロイし、develop ブランチへの push 時はステージング環境にデプロイする例です。

yamlCopy codename: デプロイワークフロー

on:
  push:
    branches:
      - main
      - develop

yamlCopy codejobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: Node.js セットアップ
  uses: actions/setup-node@v3
  with:
    node-version: '18'

yamlCopy code- name: 依存関係インストール
  run: yarn install --frozen-lockfile

yamlCopy code- name: ビルド
  run: yarn build

yamlCopy code- name: 本番環境デプロイ
  if: github.ref == 'refs/heads/main'
  run: |
    echo "本番環境にデプロイ中..."
    yarn deploy:prod
  env:
    DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}

yamlCopy code- name: ステージング環境デプロイ
  if: github.ref == 'refs/heads/develop'
  run: |
    echo "ステージング環境にデプロイ中..."
    yarn deploy:staging
  env:
    DEPLOY_TOKEN: ${{ secrets.STAGING_DEPLOY_TOKEN }}

yamlCopy code- name: デプロイ完了通知
  if: success()
  run: echo "デプロイが成功しました"

このワークフローでは、ブランチに応じて適切なデプロイ先を選択しています。 github.ref を使うことで、同じワークフローファイルでブランチごとの処理を管理できますね。

例 2：テスト失敗時の通知

テストが失敗した場合のみ、Slack に通知を送る例です。

yamlCopy codename: テストワークフロー

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: Node.js セットアップ
  uses: actions/setup-node@v3
  with:
    node-version: '18'

yamlCopy code- name: 依存関係インストール
  run: yarn install --frozen-lockfile

yamlCopy code- name: テスト実行
  run: yarn test

yamlCopy code- name: テスト失敗時の Slack 通知
  if: failure()
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    text: 'テストが失敗しました'
    webhook_url: ${{ secrets.SLACK_WEBHOOK }}

yamlCopy code- name: ログ保存（常に実行）
  if: always()
  uses: actions/upload-artifact@v3
  with:
    name: test-logs
    path: logs/

テストが失敗した場合のみ通知を送り、ログは成否に関わらず常に保存します。 これにより、不要な通知を避けつつ、必要な情報は確実に残せますね。

例 3：feature ブランチでのみ特定の処理を実行

feature ブランチでのみプレビュー環境にデプロイする例です。

yamlCopy codename: プレビューデプロイ

on:
  push:
    branches:
      - 'feature/**'

yamlCopy codejobs:
  preview:
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/heads/feature/')
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: ブランチ名取得
  id: branch
  run: |
    branch_name=${GITHUB_REF#refs/heads/}
    echo "name=${branch_name}" >> $GITHUB_OUTPUT

yamlCopy code- name: プレビュー環境デプロイ
  run: |
    echo "プレビュー環境にデプロイ中..."
    yarn deploy:preview --branch=${{ steps.branch.outputs.name }}
  env:
    PREVIEW_TOKEN: ${{ secrets.PREVIEW_DEPLOY_TOKEN }}

yamlCopy code- name: プレビュー URL をコメント
  uses: actions/github-script@v6
  with:
    script: |
      const branch = '${{ steps.branch.outputs.name }}'
      const url = `https://preview-${branch}.example.com`
      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: `プレビュー環境: ${url}`
      })

startsWith() を使うことで、feature/ で始まるブランチのみをターゲットにできます。 ブランチごとにユニークなプレビュー環境を作成し、PR にコメントすることで、レビュー効率が上がりますね。

例 4：複数条件の組み合わせ

複数の条件を組み合わせた、より高度な例です。

yamlCopy codename: 条件付きデプロイ

on: [push, pull_request]

yamlCopy codejobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: コミットメッセージ確認
  id: commit_check
  run: |
    message="${{ github.event.head_commit.message }}"
    echo "message=${message}" >> $GITHUB_OUTPUT

yamlCopy code- name: ビルド
  if: |
    github.event_name == 'push' &&
    !contains(steps.commit_check.outputs.message, '[skip ci]')
  run: yarn build

yamlCopy code- name: 本番デプロイ
  if: |
    github.ref == 'refs/heads/main' &&
    github.event_name == 'push' &&
    !contains(steps.commit_check.outputs.message, '[skip deploy]')
  run: yarn deploy:prod
  env:
    DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}

yamlCopy code- name: PR ラベル確認
  if: |
    github.event_name == 'pull_request' &&
    contains(github.event.pull_request.labels.*.name, 'ready-to-merge')
  run: echo "PR は本番デプロイ可能です"

この例では、以下の複数条件を組み合わせています。

• イベントタイプ（push または pull_request）
• ブランチ名（main ブランチのみ）
• コミットメッセージの内容（特定キーワードの有無）
• PR ラベルの有無

複雑な条件を組み合わせることで、細かい制御が可能になります。

例 5：OS ごとの条件分岐

マルチ OS 環境でのテストと、OS ごとの処理分岐の例です。

yamlCopy codename: マルチ OS テスト

on: [push, pull_request]

yamlCopy codejobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: Node.js セットアップ
  uses: actions/setup-node@v3
  with:
    node-version: '18'

yamlCopy code- name: Linux 用の依存関係インストール
  if: runner.os == 'Linux'
  run: |
    sudo apt-get update
    sudo apt-get install -y libcairo2-dev

yamlCopy code- name: macOS 用の依存関係インストール
  if: runner.os == 'macOS'
  run: |
    brew update
    brew install cairo

yamlCopy code- name: Windows 用の依存関係インストール
  if: runner.os == 'Windows'
  run: |
    choco install cairo

yamlCopy code- name: プロジェクト依存関係インストール
  run: yarn install --frozen-lockfile

yamlCopy code- name: テスト実行
  run: yarn test

yamlCopy code- name: Linux のみ：カバレッジアップロード
  if: runner.os == 'Linux'
  uses: codecov/codecov-action@v3
  with:
    files: ./coverage/lcov.info

runner.os を使うことで、OS ごとに必要な依存関係のインストール方法を切り替えられます。 カバレッジのアップロードは Linux 環境でのみ行うことで、重複を避けられますね。

例 6：環境変数とステップ出力の組み合わせ

環境変数と前ステップの出力を組み合わせた、動的な条件分岐の例です。

yamlCopy codename: 動的条件分岐

on: push

yamlCopy codeenv:
  ENABLE_E2E_TEST: 'true'
  DEPLOY_ENABLED: 'true'

yamlCopy codejobs:
  build_and_test:
    runs-on: ubuntu-latest
    outputs:
      test_result: ${{ steps.test.outputs.result }}
      coverage: ${{ steps.coverage.outputs.percentage }}
    steps:
      - name: コードチェックアウト
        uses: actions/checkout@v3

yamlCopy code- name: ユニットテスト実行
  id: test
  run: |
    yarn test
    echo "result=success" >> $GITHUB_OUTPUT

yamlCopy code- name: カバレッジ確認
  id: coverage
  run: |
    coverage=$(yarn test:coverage --json | jq -r '.total.lines.pct')
    echo "percentage=${coverage}" >> $GITHUB_OUTPUT
    echo "カバレッジ: ${coverage}%"

yamlCopy code- name: E2E テスト実行
  if: env.ENABLE_E2E_TEST == 'true'
  run: yarn test:e2e

yamlCopy codedeploy:
  needs: build_and_test
  runs-on: ubuntu-latest
  if: |
    needs.build_and_test.outputs.test_result == 'success' &&
    needs.build_and_test.outputs.coverage >= 80 &&
    env.DEPLOY_ENABLED == 'true'
  steps:
    - name: コードチェックアウト
      uses: actions/checkout@v3

yamlCopy code- name: デプロイ実行
  run: |
    echo "テスト結果: ${{ needs.build_and_test.outputs.test_result }}"
    echo "カバレッジ: ${{ needs.build_and_test.outputs.coverage }}%"
    yarn deploy:prod

yamlCopy code- name: デプロイ成功通知
  if: success()
  run: echo "デプロイが成功しました"

yamlCopy code- name: デプロイ失敗時のロールバック
  if: failure()
  run: |
    echo "デプロイに失敗したため、ロールバックします"
    yarn deploy:rollback

この例では、以下を組み合わせています。

• 環境変数による E2E テストの有効/無効切り替え
• 前ジョブの出力（テスト結果とカバレッジ）を使った条件分岐
• カバレッジが 80% 以上の場合のみデプロイを実行
• デプロイ失敗時の自動ロールバック

これにより、品質を担保しながら柔軟なデプロイフローを実現できますね。

以下の図は、この複雑なワークフローの全体像を示しています。

mermaidCopy codeflowchart TD
  start["ワークフロー開始"] --> checkout1["コードチェックアウト"]
  checkout1 --> unit_test["ユニットテスト"]

  unit_test --> coverage["カバレッジ測定"]
  coverage --> e2e_check{"E2E テスト<br/>有効?<br/>env.ENABLE_E2E_TEST"}
  e2e_check -->|"true"| e2e["E2E テスト実行"]
  e2e_check -->|"false"| job1_done["ビルド＆テスト<br/>ジョブ完了"]
  e2e --> job1_done

  job1_done --> deploy_check{"デプロイ条件確認<br/>・テスト成功?<br/>・カバレッジ≧80%?<br/>・DEPLOY_ENABLED?"}
  deploy_check -->|"すべて true"| checkout2["コードチェックアウト"]
  deploy_check -->|"いずれか false"| skip["デプロイスキップ"]

  checkout2 --> deploy["デプロイ実行"]
  deploy --> deploy_result{"デプロイ結果"}
  deploy_result -->|"成功"| notify_success["成功通知<br/>if: success()"]
  deploy_result -->|"失敗"| rollback["ロールバック<br/>if: failure()"]

  notify_success --> end_workflow["ワークフロー完了"]
  rollback --> end_workflow
  skip --> end_workflow

図で理解できる要点

• 環境変数により E2E テストの実行を制御できる
• テスト結果とカバレッジの両方が条件を満たす場合のみデプロイが実行される
• デプロイ失敗時には自動的にロールバックが実行される

まとめ

GitHub Actions の条件式を活用することで、柔軟で効率的なワークフローを構築できます。 本記事でご紹介した内容をまとめますね。

ステータスチェック関数

• success(): 前のステップが成功した場合に実行（デフォルト動作）
• failure(): 前のステップが失敗した場合に実行（エラー通知などに便利）
• always(): 成否に関わらず常に実行（クリーンアップ処理に最適）
• cancelled(): ワークフローがキャンセルされた場合に実行

文字列検索関数

• contains(値, '文字列'): 特定の文字列が含まれるかを判定
• startsWith(値, '接頭辞'): 特定の接頭辞で始まるかを判定（feature/ ブランチなどに便利）
• endsWith(値, '接尾辞'): 特定の接尾辞で終わるかを判定（ファイル拡張子の判定に便利）

コンテキスト変数

• github.event_name: イベントタイプ（push、pull_request など）による条件分岐
• github.ref: ブランチ名による条件分岐（main ブランチのみデプロイなど）
• runner.os: OS による条件分岐（Linux、macOS、Windows）
• env.変数名: 環境変数による条件分岐
• steps.ステップID.outputs.変数名: 前ステップの出力による条件分岐

論理演算子

• &&: AND 条件（すべての条件が true）
• ||: OR 条件（いずれかの条件が true）
• !: NOT 条件（条件が false）

これらの条件式を組み合わせることで、ブランチごとのデプロイ制御、テスト失敗時の通知、OS ごとの処理分岐など、さまざまなユースケースに対応できますね。

条件式を効果的に使うことで、ワークフローの実行時間を短縮し、不要な処理をスキップし、適切なタイミングで必要な処理を実行できます。 ぜひ本記事の内容を参考に、皆さんのプロジェクトに合わせた条件式を活用してみてください。

関連リンク

• GitHub Actions 公式ドキュメント - Expressions
• GitHub Actions 公式ドキュメント - Contexts
• GitHub Actions 公式ドキュメント - Workflow syntax
• GitHub Actions 公式ドキュメント - Status check functions