ワークフローのトリガー

ワークフロートリガーについて

ワークフロートリガーは、ワークフローの実行を引き起こすイベントです。次のようなイベントがあります。

ワークフローのリポジトリ内で発生するイベント
GitHub の外部で発生し、GitHub で repository_dispatch イベントをトリガーするイベント
スケジュールされた時刻
マニュアル

たとえば、リポジトリの既定のブランチに対してプッシュが行われたときや、リリースが作成されたとき、またはイシューが開かれたときに実行するようにワークフローを構成できます。

ワークフロートリガーは、on キーを使って定義されます。詳しくは、「GitHub Actions　のワークフロー構文」を参照してください。

ワークフローの実行がトリガーされるには、以下のステップが生じます。

リポジトリでイベントが発生します。イベントには、コミット SHA と Git ref が関連付けられています。
GitHub は、リポジトリのルートにある .github/workflows ディレクトリで、イベントの関連付けらたコミット SHA または Git リファレンスに存在するワークフローファイルを検索します。
トリガーするイベントと一致する on: 値を持つすべてのワークフローに対して、ワークフロー実行がトリガーされます。一部のイベントでは、実行のために、リポジトリの既定のブランチにワークフローファイルが存在している必要もあります。

各ワークフロー実行では、そのイベントに関連付けられたコミット SHA または Git ref に存在するワークフローのバージョンが使用されます。ワークフローが実行されると、GitHub によってランナー環境の GITHUB_SHA (コミット SHA) と GITHUB_REF (Git ref) の環境変数が設定されます。詳しくは、「変数に情報を格納する」を参照してください。

ワークフローからワークフローをトリガーする

リポジトリGITHUB_TOKENを使用してタスクを実行する場合、 GITHUB_TOKEN によってworkflow_dispatchトリガーされるイベント (例外) と repository_dispatch、は新しいワークフロー実行を作成しません。これによって、予想外の再帰的なワークフローの実行が生じないようになります。たとえば、ワークフロー実行でリポジトリの GITHUB_TOKEN を使用してコードがプッシュされた場合、push イベントの発生時に実行するように構成されたワークフローがリポジトリに含まれている場合でも、新しいワークフローは実行されません。詳しくは、「自動トークン認証」をご覧ください。

ワークフロー内からワークフローをトリガーする場合、トークンを必要とするイベントをトリガーする GITHUB_TOKEN の代わりに、GitHub App インストールアクセストークンまたは personal access token を使えます。

GitHub App を使う場合、GitHub App を作成し、シークレットとしてアプリ ID とプライベートキーを格納する必要があります。詳しくは、「GitHub Actions ワークフローで GitHub App を使用して認証済み API 要求を作成する」を参照してください。 personal access token を使う場合、personal access token を作成し、それをシークレットとして格納する必要があります。 personal access tokenの作成について詳しくは、「個人用アクセストークンを管理する」をご覧ください。シークレットの保管の詳細については、「GitHub Actions でのシークレットの使用」を参照してください。

GitHub Actionsの利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてください。

たとえば、次のワークフローでは、(MY_TOKEN というシークレットとして格納された) personal access token を使い、GitHub CLI を介してイシューにラベルを追加します。ラベルの追加時に実行されるすべてのワークフローは、このステップが実行されると実行されます。

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

逆に、次のワークフローでは、イシューにラベルを追加するために GITHUB_TOKEN が使用されます。ラベルの追加時に実行されるワークフローはトリガーされません。

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

イベントを使ってワークフローをトリガーする

on キーを使って、ワークフローをトリガーするイベントを指定します。使えるイベントについて詳しくは、「ワークフローをトリガーするイベント」をご覧ください。

単一のイベントを使用する

たとえば、次の on の値を持つワークフローは、ワークフローのリポジトリ内の任意のブランチにプッシュが行われるときに実行されます。

on: push

複数のイベントを使用する

1 つのイベントまたは複数のイベントを指定できます。たとえば、次の on の値を持つワークフローは、ワークフローのリポジトリ内の任意のブランチにプッシュが行われるとき、または誰かがリポジトリをフォークしたときに実行されます。

on: [push, fork]

複数のイベントを指定する場合、ワークフローをトリガーするために必要なイベントは 1 つだけです。ワークフローの複数のトリガーイベントが同時に発生した場合、複数のワークフロー実行がトリガーされます。

アクティビティの種類とフィルターを複数のイベントと共に使用する

アクティビティの種類とフィルターを使って、ワークフローを実行するタイミングをさらに細かく制御できます。詳細については、「イベントアクティビティの種類を使用する」と「フィルターを使用する」を参照してください。イベントにアクティビティの種類やフィルターを指定し、ワークフローが複数のイベントでトリガーされる場合、各イベントを個別に構成する必要があります。構成しないイベントも含め、すべてのイベントにはコロン (:) を追加する必要があります。

たとえば、以下の on の値を持つワークフローは、次のような場合に実行されます。

ラベルが作成されたとき
リポジトリ内の main ブランチにプッシュされたとき
GitHub Pages 対応のブランチにプッシュされたとき

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

イベントアクティビティの種類を使用する

一部のイベントには、ワークフローを実行するタイミングをより細かく制御できるアクティビティの種類があります。 on.<event_name>.types を使用して、ワークフロー実行をトリガーするイベントアクティビティの種類を定義します。

たとえば、issue_comment イベントには、created、edited、deleted のアクティビティの種類があります。 label イベントでワークフローがトリガーされる場合、ラベルが作成、編集、または削除されるたびにワークフローが実行されます。 label イベントに created アクティビティの種類を指定すると、ワークフローはラベルの作成時に実行されますが、ラベルの編集または削除時には実行されません。

on:
  label:
    types:
      - created

複数のアクティビティの種類を指定した場合、ワークフローをトリガーするために発生する必要があるのは、それらのイベントアクティビティの種類のうちの 1 つだけです。ワークフローの複数のトリガーイベントアクティビティの種類が同時に発生した場合、複数のワークフロー実行がトリガーされます。たとえば、次のワークフローは、Issue がオープンされた場合またはラベル付けされた場合にトリガーされます。 2 つのラベルを持つ Issue がオープンされると、3 つのワークフロー実行 (1 つは Issue がオープンされたイベント用、2 つは Issue のラベルが付いたイベント用) が開始されます。

on:
  issues:
    types:
      - opened
      - labeled

各イベントとそのアクティビティの種類の詳細については、「ワークフローをトリガーするイベント」を参照してください。

フィルターを使用する

一部のイベントには、ワークフローを実行するタイミングをより細かく制御できるフィルターがあります。

たとえば、push イベントの branches フィルターでは、プッシュが発生したときではなく、branches フィルターと同じブランチに対してプッシュが発生したときのみ、ワークフローを実行できます。

on:
  push:
    branches:
      - main
      - 'releases/**'

フィルターを使用して pull request イベントに対して特定のブランチをターゲットにする

pull_request イベントと pull_request_target イベントを使用する場合は、特定のブランチを対象とする pull request に対してのみ実行するようにワークフローを構成できます。

ブランチ名パターンを包含する場合、またはブランチ名パターンの包含と除外の両方を行う場合は、branches フィルターを使用します。ブランチ名パターンの除外のみを行う場合は、branches-ignore フィルターを使用します。 branches と branches-ignore のフィルターの両方をワークフロー内の同じイベントで使うことはできません。

branches/branches-ignore と paths/paths-ignore の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。

branches と branches-ignore のキーワードは、複数のブランチ名に一致する文字 (*、**、+、?、! など) を使用する glob パターンを受け入れます。名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、\ でこれらの各特殊文字をエスケープする必要があります。 glob パターンの詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

例: ブランチの包含

branches で定義されているパターンは、Git ref の名前に対して評価されます。たとえば、次のワークフローは、pull request の対象となる pull_request イベントが発生するたびに実行されます。

main という名前のブランチ (refs/heads/main)
mona/octocat という名前のブランチ (refs/heads/mona/octocat)
releases/10 のように名前が releases/ で始まるブランチ (refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

ブランチフィルター、パスフィルター、またはコミットメッセージのためにワークフローがスキップされる場合、そのワークフローに関連付けられているチェックは "保留中" 状態のままになります。これらのチェックを成功させる必要がある pull request は、マージが禁止されます。

例: ブランチの除外

パターンが branches-ignore パターンと一致する場合、ワークフローは実行されません。 branches-ignore で定義されているパターンは、Git ref の名前に対して評価されます。たとえば、次のワークフローは、pull request の対象とならない限り、pull_request イベントが発生するたびに実行されます。

mona/octocat という名前のブランチ (refs/heads/mona/octocat)
名前が releases/beta/3-alpha のように releases/**-alpha と一致するブランチ (refs/heads/releases/beta/3-alpha)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

例: パスの包含および除外

1 つのワークフローで同じイベントのフィルター処理をするために branches と branches-ignore を使用することはできません。 1 つのイベントに対して分岐パターンの適用と除外の両方を行う場合は、branches フィルターと ! 文字を使用して、除外する分岐を指定します。

! 文字を含むブランチを定義する場合は、! 文字を含まないブランチも 1 つ以上定義する必要があります。ブランチの除外のみを行いたい場合は、代わりに branches-ignore を使用します。

パターンを定義する順序により、結果に違いが生じます。

肯定のマッチングパターンの後に否定のマッチングパターン (! のプレフィックスが付く) を定義すると、Git ref が除外されます。
否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。

次のワークフローは、否定のパターン !releases/**-alpha が肯定のパターンの後に続くため、releases/10 または releases/beta/mona を対象とする pull request の pull_request イベントで実行されますが、releases/10-alpha または releases/beta/3-alpha を対象とする pull request では実行されません。

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

フィルターを使用してプッシュイベントに対して特定のブランチまたはタグをターゲットにする

push イベントを使用する場合は、特定のブランチまたはタグで実行するワークフローを構成できます。

ブランチ名パターンを含める場合、またはブランチ名パターンを含める/除外の両方を行う場合は、branches フィルターを使用します。ブランチ名パターンの除外のみを行う場合は、branches-ignore フィルターを使用します。 branches と branches-ignore のフィルターの両方をワークフロー内の同じイベントで使うことはできません。

タグ名パターンを含める場合、またはタグ名パターンを含める/除外の両方を行う場合は、tags フィルターを使用します。タグ名パターンの除外のみを行う場合は、tags-ignore フィルターを使用します。 tags と tags-ignore のフィルターの両方をワークフロー内の同じイベントで使うことはできません。

tags/tags-ignore または branches/branches-ignore だけを定義する場合、定義されていない Git ref に影響を与えるイベントに対してワークフローは実行されません。tags/tags-ignore および branches/branches-ignore のどちらも定義しない場合、ワークフローはブランチまたはタグに影響を与えるイベントに対して実行されます。 branches/branches-ignore と paths/paths-ignore の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。

branches、branches-ignore、tags、および tags-ignore のキーワードは、複数のブランチまたはタグ名に一致する文字 (*、**、+、?、! など) を使用する glob パターンを許容します。名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、\ でこれらの各特殊文字を_エスケープ_する必要があります。 glob パターンの詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

ブランチとタグを含める例

branches と tags で定義されているパターンは、Git ref の名前に対して評価されます。たとえば、次のワークフローは、push イベントが発生するたびに実行されます。

main という名前のブランチ (refs/heads/main)
mona/octocat という名前のブランチ (refs/heads/mona/octocat)
releases/10 のように名前が releases/ で始まるブランチ (refs/heads/releases/10)
v2 という名前のタグ (refs/tags/v2)
v1.9.1 のように名前が v1. で始まるタグ (refs/tags/v1.9.1)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

ブランチやタグを除外する例

パターンが branches-ignore または tags-ignore パターンと一致する場合、ワークフローは実行されません。 branches と tags で定義されているパターンは、Git ref の名前に対して評価されます。たとえば、次のワークフローは、push イベントがない限り、push イベントが発生するたびに実行されます。

mona/octocat という名前のブランチ (refs/heads/mona/octocat)
releases/beta/3-alpha のように名前が releases/**-alpha と一致するブランチ (refs/heads/releases/beta/3-alpha)
v2 という名前のタグ (refs/tags/v2)
v1.9 のように名前が v1. で始まるタグ (refs/tags/v1.9)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v2
      - v1.*

ブランチやタグを含めたり除外したりする例

1 つのワークフローで同じイベントをフィルターするために branches と branches-ignore を使用することはできません。同様に、1 つのワークフローで同じイベントをフィルターするために tags と tags-ignore を使用することはできません。 1 つのイベントに対してブランチまたはタグパターンを含める/除外の両方を行う場合は、branches または tags フィルターと ! 文字を使用して、除外するブランチまたはタグを指定します。

! 文字を含むブランチを定義する場合は、! 文字を含まないブランチも 1 つ以上定義する必要があります。ブランチの除外のみを行いたい場合は、代わりに branches-ignore を使用します。同様に、! 文字を含むタグを定義する場合は、! 文字を含まないタグも 1 つ以上定義する必要があります。タグの除外のみを行いたい場合は、代わりに tags-ignore を使用します。

パターンを定義する順序により、結果に違いが生じます。

肯定のマッチングパターンの後に否定のマッチングパターン (! のプレフィックスが付く) を定義すると、Git ref が除外されます。
否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。

次のワークフローは、否定パターン !releases/**-alpha が肯定パターンに従うため、releases/10 または releases/beta/mona へのプッシュで実行され、releases/10-alpha または releases/beta/3-alpha では実行されません。

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

フィルターを使用して pull request またはプッシュイベントに対して特定のパスをターゲットにする

push と pull_request のイベントを使用すると、変更されるファイルパスに基づいて実行するワークフローを構成できます。タグのプッシュに対して、パスのフィルターは評価されません。

ファイルパスパターンを包含する場合、またはファイルパスパターンの包含と除外の両方を行う場合は、paths フィルターを使用します。ファイルパスパターンの除外のみを行う場合は、paths-ignore フィルターを使用します。 paths と paths-ignore のフィルターの両方をワークフロー内の同じイベントで使うことはできません。 1 つのイベントに対してパスパターンの包含と除外の両方を行う場合は、除外するパスを示すために! 文字を接頭辞にしたpathsフィルタを使用します。

Note

pathsパターンを定義する順序により、結果に違いが生じます:

肯定のマッチングパターンの後に否定のマッチングパターン（! のプレフィックスが付く）を定義すると、パスを除外します。
否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。

branches/branches-ignore と paths/paths-ignore の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。

paths と paths-ignore のキーワードは、複数のパス名と一致するために * と ** のワイルドカード文字を使用する glob パターンを受け入れます。詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

例: パスの包含

paths フィルターにパターンにマッチするパスが 1 つでもあれば、ワークフローは実行されます。たとえば、次のワークフローは、JavaScript ファイル (.js) をプッシュするたびに実行されます。

on:
  push:
    paths:
      - '**.js'

パスフィルター、ブランチフィルター、またはコミットメッセージのためにワークフローがスキップされる場合、そのワークフローに関連付けられているチェックは "保留中" 状態のままになります。これらのチェックを成功させる必要がある pull request は、マージが禁止されます。

例: パスの除外

すべてのパス名が paths-ignore のパターンと一致する場合、ワークフローは実行されません。パス名が paths-ignore のパターンと一致しない場合は、一部のパス名がパターンと一致する場合でも、ワークフローが実行されます。

以下のパスのフィルターを持つワークフローは、リポジトリのルートにある docs ディレクトリ外のファイルを少なくとも 1 つ含む push イベントでのみ実行されます。

on:
  push:
    paths-ignore:
      - 'docs/**'

例: パスの包含および除外

1 つのワークフローで同じイベントのフィルター処理をするために paths と paths-ignore を使用することはできません。 1 つのイベントに対してパスパターンの包含と除外の両方を行う場合は、除外するパスを示すために! 文字を接頭辞にしたpathsフィルタを使用します。

! 文字を含むパスを定義する場合は、! 文字を含まないパスも 1 つ以上定義する必要があります。パスの除外のみを行いたい場合は、代わりに paths-ignore を使用します。

pathsパターンを定義する順序により、結果に違いが生じます:

肯定のマッチングパターンの後に否定のマッチングパターン（! のプレフィックスが付く）を定義すると、パスを除外します。
否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。

ファイルが sub-project/docs ディレクトリに存在しない限り、push イベントが sub-project ディレクトリまたはそのサブディレクトリのファイルを含む場合は、この例はいつでも実行されます。たとえば、sub-project/index.js または sub-project/src/index.js を変更するプッシュはワークフローの実行をトリガーしますが、sub-project/docs/readme.md のみを変更するプッシュはワークフローの実行をトリガーしません。

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Git diffの比較

Note

1,000 以上のコミットをプッシュする場合、あるいは GitHub がタイムアウトのために diff を生成できない場合、そのワークフローは常に実行されます。

フィルターは、変更されたファイルを評価し、paths-ignore または paths のリストに対してファイルを実行することで、ワークフローを実行すべきか判断します。ファイルが変更されていない場合、ワークフローは実行されません。

GitHubはプッシュに対してはツードットdiff、Pull Requestに対してはスリードットdiffを使って変更されたファイルのリストを生成します。

pull request: スリードット diff は、トピックブランチの最新バージョンとトピックブランチがベースブランチと最後に同期されたコミットとの比較です。
既存のブランチへのプッシュ: ツードット diff は、ヘッド SHA とベース SHA を互いに直接比較します。
新しいブランチへのプッシュ: プッシュされた最も深いコミットの先祖の親に対するツードット diff です。

diff は 300 個のファイルに制限されます。フィルターによって返された最初の 300 個のファイルに一致しないファイルが変更された場合、ワークフローは実行されません。ワークフローが自動的に実行されるように、より具体的なフィルターを作成する必要がある場合があります。

詳しくは、「プルリクエスト中でのブランチの比較について」を参照してください。

フィルターを使用してワークフロー実行イベントに対して特定のブランチをターゲットにする

workflow_run イベントを使用する場合は、ワークフローをトリガーするためにトリガーするワークフローが稼働する必要があるブランチを指定できます。

branches フィルターと branches-ignore フィルターは、複数のブランチ名に一致する文字 (*、**、+、? など) を使用する glob パターンを受け入れます。! 名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、\ でこれらの各特殊文字を_エスケープ_する必要があります。 glob パターンの詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

たとえば、次のトリガーを持つワークフローは、名前が releases/ で始まるブランチで Build という名前のワークフローが稼働している場合にのみ実行されます。

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

次のトリガーを持つワークフローは、名前が canary でないブランチで Build という名前のワークフローが稼働している場合にのみ実行されます。

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

branches と branches-ignore のフィルターの両方をワークフロー内の同じイベントで使うことはできません。 1 つのイベントに対して分岐パターンの適用と除外の両方を行う場合は、branches フィルターと ! 文字を使用して、除外する分岐を指定します。

パターンを定義する順序により、結果に違いが生じます。

肯定のマッチングパターンの後に否定のマッチングパターン（! のプレフィックスが付く）を定義すると、ブランチを除外します。
否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、ブランチを再び含めます。

たとえば、次のトリガーを持つワークフローは、名前が releases/10 または releases/beta/mona で始まるブランチで Build という名前のワークフローが稼働している場合にのみ実行されますが、releases/10-alpha、releases/beta/3-alpha または main という名前のブランチでは実行されません。

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

手動でトリガーされるワークフローの入力を定義する

workflow_dispatch イベントを使用すると、必要に応じてワークフローに渡される入力を指定できます。

このトリガーは、ワークフローファイルが既定のブランチにある場合に限りイベントを受信します。トリガーされたワークフローは、inputs コンテキストの入力を受け取ります。詳細については、「コンテキスト」を参照してください。

Note

ワークフローは、github.event.inputs コンテキスト内の入力も受け取ります。 inputs コンテキストと github.event.inputs コンテキストの情報ですが、inputs コンテキストではブール値が文字列に変換されず、ブール値として保持されます。 choice 型は文字列に解決され、1 つの選択可能なオプションです。
inputs の最上位レベルのプロパティの最大数は 10 です。
inputs のペイロードの最大数は 65,535 文字です。

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
          - info
          - warning
          - debug
      print_tags:
        description: 'True to print to STDOUT'
        required: true
        type: boolean
      tags:
        description: 'Test scenario tags'
        required: true
        type: string
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if:  ${{ inputs.print_tags }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ inputs.tags }}

再利用可能なワークフローの入力、出力、シークレットを定義する

再利用可能なワークフローが呼び出し元のワークフローから受け取る入力とシークレットを定義できます。また、再利用可能なワークフローが呼び出し元のワークフローで使用できるようにする出力を指定することもできます。詳しくは、「ワークフローの再利用」を参照してください。

イベント情報を使用する

ワークフロー実行をトリガーしたイベントに関する情報は、github.event コンテキストで使用できます。 github.event コンテキストのプロパティは、ワークフローをトリガーしたイベントの種類によって異なります。たとえば、イシューがラベル付けされたときにトリガーされるワークフローでは、そのイシューとラベルに関する情報が含まれます。

イベントのすべてのプロパティを表示する

一般的なプロパティとペイロードの例については、webhook イベントのドキュメントを参照してください。詳しくは、「Webhook のイベントとペイロード」を参照してください。

また、github.event コンテキスト全体を出力して、ワークフローをトリガーしたイベントで使用できるプロパティを確認することもできます。

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

イベントプロパティへのアクセスと使用

ワークフローで github.event コンテキストを使用できます。たとえば、次のワークフローは、package*.json、.github/CODEOWNERS、または .github/workflows/** を変更する pull request が開かれると実行されます。 pull request の作成者 (github.event.pull_request.user.login) が octobot でも dependabot[bot] でもない場合、ワークフローでは GitHub CLI を使用して pull request へのラベル付けとコメントを行います (github.event.pull_request.number)。

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

コンテキストについて詳しくは、「ワークフロー実行に関するコンテキスト情報へのアクセス」をご覧ください。イベントペイロードについて詳しくは、「Webhook のイベントとペイロード」をご覧ください。

ワークフローの実行方法をさらに細かく制御する

イベント、イベントアクティビティの種類、またはイベントフィルターによる制御よりもさらに細かい制御が必要な場合は、条件と環境を使って、ワークフロー内の個々のジョブまたはステップを実行するかどうかを制御できます。

条件の使用

条件を使って、ワークフロー内のジョブまたはステップを実行するかどうかをさらに細かく制御できます。

イベントペイロードの値を使用する例

たとえば、イシューに特定のラベルが追加されたときにワークフローを実行したい場合は、issues labeled イベントアクティビティの種類に対してトリガーし、条件を使ってワークフローをトリガーしたラベルをチェックすることができます。次のワークフローは、ワークフローのリポジトリ内のイシューに任意のラベルが追加されたときに実行されますが、run_if_label_matches ジョブが実行されるのはラベルの名前が bug である場合のみです。

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

イベントの種類を使用する例

たとえば、ワークフローをトリガーしたイベントに応じて異なるジョブまたはステップを実行したい場合は、条件を使って、イベントコンテキストに特定のイベントの種類が存在するかどうかをチェックできます。次のワークフローは、イシューまたは pull request がクローズされるたびに実行されます。イシューがクローズされたためにワークフローが実行された場合、github.event コンテキストには issue の値が含まれますが、pull_request の値は含まれません。したがって、if_issue ステップは実行されますが、if_pr ステップは実行されません。逆に、pull request がクローズされたためにワークフローが実行された場合、if_pr ステップは実行されますが、if_issue ステップは実行されません。

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

イベントコンテキストで使用できる情報について詳しくは、「イベント情報を使用する」を参照してください。条件を使う方法について詳しくは、「ワークフローとアクションで式を評価する」をご覧ください。

環境を使用してワークフロージョブを手動でトリガーする

ワークフロー内の特定のジョブを手動でトリガーしたい場合は、特定のチームまたはユーザーからの承認を必要とする環境を使用できます。まず、必要なレビュー担当者を使用して環境を構成します。詳しくは、「デプロイに環境の使用」を参照してください。次に、environment: キーを使って、ワークフロー内のジョブで環境名を参照します。環境を参照するジョブは、少なくとも 1 人のレビュー担当者がそのジョブを承認するまで実行されません。

たとえば、次のワークフローは、main へのプッシュが発生するたびに実行されます。 build ジョブは常に実行されます。 publish ジョブは、build ジョブが正常に完了し (needs: [build] による)、production という環境のすべてのルール (必要なレビュー担当者を含む) に合格した (environment: production による) ときに初めて実行されます。

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        echo 'publishing'

環境、環境シークレット、およびデプロイ保護ルールは、現在のすべての GitHub プランのパブリックリポジトリで使用できます。ブロンズ、シルバー、ゴールドなどの従来のプランでは使用できません。プライベートまたは内部リポジトリ内の環境、環境のシークレット、デプロイブランチにアクセスするには、GitHub Pro、GitHub Team または GitHub Enterprise を使う必要があります。 GitHub Free プラン、GitHub Pro プラン、または GitHub Team プランを使用している場合、待機タイマーや必須のレビュー担当者など、他のデプロイ保護ルールはパブリックリポジトリでのみ使用できます。

使用できるイベント

使えるすべてのイベントの一覧については、「ワークフローをトリガーするイベント」をご覧ください。

ワークフローのトリガー

この記事の内容