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

ワークフローをトリガーするイベントについて

ワークフロー トリガーは、ワークフローの実行を引き起こすイベントです。 ワークフロー トリガーの使い方について詳しくは、「ワークフローをトリガーする」をご覧ください。

イベントによっては、複数のアクティビティの種類があります。 このようなイベントでは、ワークフローの実行をトリガーするアクティビティの種類を指定できます。 各アクティビティの種類の意味について詳しくは、「Webhook のイベントとペイロード」をご覧ください。

branch_protection_rule

ワークフロー リポジトリ内のブランチ保護ルールが変更されたときにワークフローを実行します。 ブランチ保護ルールについて詳しくは、「保護されたブランチについて」をご覧ください。 ブランチ保護ルール API については、GraphQL API ドキュメントの「オブジェクト」または「ブランチとその設定用 REST API エンドポイント」をご覧ください。

たとえば、ブランチ保護ルールが created または deleted だったときにワークフローを実行できます。

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

チェック実行に関連するアクティビティが発生したときにワークフローを実行します。 チェックの実行は、個別のテストであり、チェックスイートの一機能です。 詳しくは、「REST API を使用してチェックを操作する」を参照してください。 チェック実行 API については、GraphQL API ドキュメントの「オブジェクト」または「チェック実行用 REST API エンドポイント」をご覧ください。

たとえば、チェック実行が rerequested または completed だったときにワークフローを実行できます。

on:
  check_run:
    types: [rerequested, completed]

check_suite

チェック スイートのアクティビティが発生したときにワークフローを実行します。 チェック スイートは、特定のコミットに対して作成されたチェック実行のコレクションです。 チェック スイートでは、スイート内のチェック実行の状態と結果をまとめます。 詳しくは、「REST API を使用してチェックを操作する」を参照してください。 チェック スイート API については、GraphQL API ドキュメントの「オブジェクト」または「チェック スイート用 REST API エンドポイント」をご覧ください。

たとえば、チェック スイートが completed だったときにワークフローを実行できます。

on:
  check_suite:
    types: [completed]

create

誰かがワークフローのリポジトリに Git 参照 (Git ブランチまたはタグ) を作成したときにワークフローを実行します。 Git 参照を作成するための API については、GraphQL API ドキュメントの「変異」または「Git リファレンス用 REST API エンドポイント」をご覧ください。

たとえば、create イベントが発生したときにワークフローを実行できます。

on:
  create

delete

誰かがワークフローのリポジトリで Git 参照 (Git ブランチまたはタグ) を削除したときにワークフローを実行します。 Git 参照を削除するための API については、GraphQL API ドキュメントの「変異」または「Git リファレンス用 REST API エンドポイント」をご覧ください。

たとえば、delete イベントが発生したときにワークフローを実行できます。

on:
  delete

deployment

誰かがワークフローのリポジトリにデプロイを作成したときにワークフローを実行します。 コミット SHA を使って作成されたデプロイには、Git ref がない場合があります。デプロイを作成するための API については、「変異」(GraphQL API ドキュメント) または「リポジトリの REST API エンドポイント」をご覧ください。

たとえば、deployment イベントが発生したときにワークフローを実行できます。

on:
  deployment

deployment_status

サード パーティによってデプロイの状態が提供されたときにワークフローを実行します。 コミット SHA を使って作成されたデプロイには、Git ref がない場合があります。デプロイ状態を作成するための API については、GraphQL API ドキュメントの「変異」または「デプロイ用の REST API エンドポイント」をご覧ください。

たとえば、deployment_status イベントが発生したときにワークフローを実行できます。

on:
  deployment_status

discussion

ワークフローのリポジトリ内のディスカッションが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントに関連するアクティビティには、discussion_comment イベントを使います。 ディスカッションについて詳しくは、「ディスカッションについて」をご覧ください。 GraphQL API については、「オブジェクト」をご覧ください。

たとえば、ディスカッションが created、edited、または answered だったときにワークフローを実行できます。

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

ワークフローのリポジトリ内のディスカッションのコメントが作成または変更されたときにワークフローを実行します。 ディスカッションのコメントではなくディスカッションに関連するアクティビティには、discussion イベントを使います。 ディスカッションについて詳しくは、「ディスカッションについて」をご覧ください。 GraphQL API については、「オブジェクト」をご覧ください。

たとえば、ディスカッション コメントが created または deleted だったときにワークフローを実行できます。

on:
  discussion_comment:
    types: [created, deleted]

fork

誰かがリポジトリをフォークしたときにワークフローを実行します。 REST API については、「フォーク用の REST API エンドポイント」をご覧ください。

たとえば、fork イベントが発生したときにワークフローを実行できます。

on:
  fork

gollum

誰かが Wiki ページを作成または更新したときにワークフローを実行します。 詳しくは、「ウィキについて」をご覧ください。

たとえば、gollum イベントが発生したときにワークフローを実行できます。

on:
  gollum

image_version

指定したイメージの新しいバージョンが使用できるようになると、ワークフローを実行します。 このイベントは通常、イメージ バージョンの作成が成功した後にトリガーされ、新しいイメージ バージョンに応答してデプロイや通知などのアクションを自動化できます。

このイベントは、イメージ名とバージョンの両方の glob パターンをサポートします。 次の例では、新しいイメージ バージョンが、指定した名前とバージョンの組み合わせのいずれかに一致するとトリガーされます。 たとえば、 ["MyNewImage", 1.0.0]、 ["MyNewImage", 2.53.0]、 ["MyOtherImage", 1.0.0]、 ["MyOtherImage", 2.0.0]などです。

on:
  image_version:
    names:
    - "MyNewImage"
    - "MyOtherImage"
    versions:
    - 1.*
    - 2.*

issue_comment

issue または pull request のコメントが作成、編集、または削除されたときにワークフローを実行します。 issue コメント API についての情報は、GraphQL API ドキュメントの「オブジェクト」または REST API ドキュメントの「Webhook のイベントとペイロード」をご確認ください。

たとえば、issue または pull request のコメントが created または deleted だったときにワークフローを実行できます。

on:
  issue_comment:
    types: [created, deleted]

問題のみまたはプル リクエストのみの issue_comment

          `issue_comment` イベントは、issue と pull request の両方に関するコメントで発生します。 条件で `github.event.issue.pull_request` プロパティを使うと、トリガーするオブジェクトが issue か pull request かによって異なるアクションを実行できます。

たとえば、このワークフローでは、pr_commented イベントが pull request から発生した場合にのみ issue_comment ジョブを実行します。 issue_commented イベントが issue から発生した場合にのみ issue_comment ジョブが実行されます。

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

issues

ワークフローのリポジトリ内の issue が作成または変更されたときにワークフローを実行します。 issue のコメントに関連するアクティビティには、issue_comment イベントを使います。 問題について詳しくは、「問題について」をご覧ください。 issue API について詳しくは、GraphQL API ドキュメントの「オブジェクト」または「問題用の REST API エンドポイント」をご覧ください。

たとえば、issue が opened、edited、または milestoned だったときにワークフローを実行できます。

on:
  issues:
    types: [opened, edited, milestoned]

label

ワークフローのリポジトリ内のラベルが作成または変更されたときにワークフローを実行します。 ラベルについて詳しくは、「ラベルを管理する」をご覧ください。 ラベル API については、GraphQL API ドキュメントの「オブジェクト」または「ラベル用の REST API エンドポイント」をご覧ください。

issue、pull request、またはディスカッションにラベルが追加されるか削除されたときにワークフローを実行したい場合は、代わりに labeled または unlabeled アクティビティタイプを issues、pull_request、pull_request_target、または discussion イベントに使用します。

たとえば、ラベルが created または deleted だったときにワークフローを実行できます。

on:
  label:
    types: [created, deleted]

merge_group

マージ キューに pull request が追加されたときにワークフローを実行し、マージ グループにその pull request を追加します。 詳しくは、「pull request とマージ キューのマージ」をご覧ください。

たとえば、checks_requested イベントが発生したときにワークフローを実行できます。

on:
  pull_request:
    branches: [ "main" ]
  merge_group:
    types: [checks_requested]

milestone

ワークフローのリポジトリ内のマイルストーンが作成または変更されたときにワークフローを実行します。 マイルストーンについて詳しくは、「マイルストーンについて」をご覧ください。 マイルストーン API については、GraphQL API ドキュメントの「オブジェクト」または「マイルストーン用の REST API エンドポイント」をご覧ください。

マイルストーンに課題が追加または削除されたときにワークフローを実行したい場合は、milestoned イベントではなく、代わりにアクティビティの種類として demilestoned または issues を使用してください。

たとえば、マイルストーンが opened または deleted だったときにワークフローを実行できます。

on:
  milestone:
    types: [opened, deleted]

page_build

リポジトリに対して GitHub Pages が有効になっている場合、GitHub Pages の公開元であるブランチに誰かがプッシュしたときにワークフローを実行します。 GitHub Pages の発行元について詳しくは、「GitHub Pages サイトの発行ソースの構成」をご覧ください。 REST API については、「リポジトリの REST API エンドポイント」をご覧ください。

たとえば、page_build イベントが発生したときにワークフローを実行できます。

on:
  page_build

public

ワークフローのリポジトリがプライベートからパブリックに変更されたときにワークフローを実行します。 REST API については、「リポジトリの REST API エンドポイント」をご覧ください。

たとえば、public イベントが発生したときにワークフローを実行できます。

on:
  public

pull_request

          `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` |

          `pull_request` webhook イベント ペイロードは、マージされた pull request とフォークされたリポジトリから取得された pull request に対して空です。

GITHUB_REF の値は、プルリクエストがマージされたかどうかに応じて、クローズされたプルリクエストの場合、異なります。 pull request はクローズされたが、マージされていない場合は refs/pull/PULL_REQUEST_NUMBER/merge になります。 マージの結果としてプル リクエストがクローズされた場合は、マージ先のブランチの完全修飾の ref (/refs/heads/main など) になります。

ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない場合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。 pull request レビュー、pull request レビュー コメント、または pull request コメントに関連するアクティビティには、代わりに pull_request_review、pull_request_review_comment、または issue_comment イベントを使います。 pull request API については、GraphQL API ドキュメントの「オブジェクト」または「Pull request 用 REST API エンドポイント」をご覧ください。

このイベントの GITHUB_SHA が pull request マージ ブランチの最後のマージ コミットであることに注意してください。 pull request の head ブランチへの最後のコミットのコミット ID を取得する場合は、代わりに github.event.pull_request.head.sha を使います。

たとえば、pull request を開いたり再度開いたりしたときにワークフローを実行できます。

on:
  pull_request:
    types: [opened, reopened]

イベント コンテキストを使って、ワークフロー内のジョブを実行するタイミングをさらに制御できます。 たとえば、このワークフローは pull request でレビューが要求されたときに実行されますが、specific_review_requested ジョブは octo-team によるレビューの要求時にのみ実行されます。

on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'

pull request の head またはベース ブランチに基づいて pull_request ワークフローを実行する

          `branches` または `branches-ignore` フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)」をご覧ください。

たとえば、このワークフローは、名前が releases/ で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で github.head_ref コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が run_if で始まる名前のブランチである場合にのみ releases/ ジョブが実行されます。

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if: startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull request で変更されたファイルに基づいて pull_request ワークフローを実行する

また、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

たとえば、このワークフローは、pull request に JavaScript ファイル (.js) への変更が含まれているときに実行されます。

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull request がマージされたときに pull_request ワークフローが実行されるようにする

pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの pull_request 値を検査する条件とともにイベントの種類 closed``merged を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。 if_merged ジョブは、pull request もマージされた場合にのみ実行されます。

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリからの pull request での読み取り専用アクセス許可があります。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベース リポジトリへの pull request、GitHub は、pull_request、issue_comment、pull_request_review_comment、pull_request_review、pull_request_target イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「フォークからのワークフロー実行の承認」をご覧ください。

フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「リポジトリのGitHub Actions設定の管理」を参照してください。

          `pull_request_comment` (`issue_comment` を使用)

プル リクエストの差分ではなくプル リクエストでコメントが作成、編修、削除されたときにワークフローを実行するには、issue_comment イベントを使います。 pull request レビューまたは pull request レビュー コメントに関連するアクティビティには、pull_request_review または pull_request_review_comment イベントを使います。

pull_request_review

          `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` |

pull request レビューが送信、編集、または却下された場合にワークフローを実行します。 pull request レビューは、本文コメントと状態に加えて、pull request レビュー コメントのグループです。 pull request レビュー コメントまたは pull request コメントに関連するアクティビティには、代わりに pull_request_review_comment または issue_comment イベントを使います。 pull request レビュー API については、GraphQL API ドキュメントの「オブジェクト」または「Pull request 用 REST API エンドポイント」をご覧ください。

たとえば、pull request レビューが edited または dismissed だったときにワークフローを実行できます。

on:
  pull_request_review:
    types: [edited, dismissed]

pull request が承認されたときにワークフローを実行する

pull request が承認されたときにワークフローを実行するには、種類 submitted の pull_request_review イベントを使ってワークフローをトリガーし、github.event.review.state プロパティを使ってレビューの状態を確認します。 たとえば、このワークフローは pull request レビューが送信されるたびに実行されますが、approved ジョブは、送信されたレビューが承認レビューである場合にのみ実行されます。

on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリからの pull request での読み取り専用アクセス許可があります。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベース リポジトリへの pull request、GitHub は、pull_request、issue_comment、pull_request_review_comment、pull_request_review、pull_request_target イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「フォークからのワークフロー実行の承認」をご覧ください。

フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「リポジトリのGitHub Actions設定の管理」を参照してください。

pull_request_review_comment

          `GITHUB_REF` ブランチでの最後のマージ コミット | PR マージ ブランチ `refs/pull/PULL_REQUEST_NUMBER/merge` |

pull request レビュー コメントが変更されたときにワークフローを実行します。 pull request レビュー コメントは、pull request の差分に関するコメントです。 pull request レビューまたは pull request コメントに関連するアクティビティには、代わりに pull_request_review または issue_comment イベントを使います。 pull request レビュー コメント API については、GraphQL API ドキュメントの「オブジェクト」または「Pull request 用 REST API エンドポイント」をご覧ください。

たとえば、pull request レビュー コメントが created または deleted だったときにワークフローを実行できます。

on:
  pull_request_review_comment:
    types: [created, deleted]

フォークされたリポジトリのワークフロー

デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 GitHub アクションは、フォークされたリポジトリの [アクション] タブで有効にする必要があります。

GITHUB_TOKEN の例外を除き、ワークフローがフォークされたリポジトリからトリガーされた場合、シークレットはランナーに渡されません。 GITHUB_TOKEN には、フォークされたリポジトリからの pull request での読み取り専用アクセス許可があります。 詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

フォークしたリポジトリのプルリクエストイベント

フォークされたリポジトリからベース リポジトリへの pull request、GitHub は、pull_request、issue_comment、pull_request_review_comment、pull_request_review、pull_request_target イベントをベース リポジトリに送信します。 フォークされたリポジトリでは、pull request イベントは発生しません。

初めてのコントリビューターがパブリックリポジトリに pull request をサブミットした場合、書き込み権限を持つメンテナがその pull request に対するワークフローの実行を承認しなければならないことがあります。 詳しくは、「フォークからのワークフロー実行の承認」をご覧ください。

フォークされたリポジトリからプライベート リポジトリへの pull request、ワークフローは有効になっている場合にのみ実行されます。「リポジトリのGitHub Actions設定の管理」を参照してください。

pull_request_target

ワークフローのリポジトリ内の pull request のアクティビティが発生したときにワークフローを実行します。 たとえば、アクティビティの種類が指定されていない場合、pull request を開いたり、再度開いたりしたとき、または pull request の head ブランチが更新されたときにワークフローが実行されます。

このイベントは、基本リポジトリのデフォルトブランチのコンテキストで、pull_requestイベントのようにマージコミットではなく実行されます。 これで、リポジトリを変更したり、ワークフローで使うシークレットを盗んだりする可能性がある、pull request の head から安全ではないコードが実行されるのが避けられます。 このイベントを使うと、ワークフローでは、pull request に対するラベルやコメントなどの作業をフォークから行うことができます。 pull request からコードをビルドまたは実行する必要がある場合は、このイベントを使わないでください。

リポジトリのセキュリティを維持するため、特定のパターン (SHA に似ているものなど) と一致する名前を持つブランチからは、pull_request_target イベントでワークフローがトリガーされない場合があります。

たとえば、pull request が assigned、opened、synchronize、または reopened だったときにワークフローを実行できます。

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

pull request の head またはベース ブランチに基づいて pull_request_target ワークフローを実行する

          `branches` または `branches-ignore` フィルターを使って、特定のブランチを対象とする pull request でのみ実行するようにワークフローを構成できます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)」をご覧ください。

たとえば、このワークフローは、名前が releases/ で始まるブランチを対象とする pull request を誰かが開いたときに実行されます。

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

(pull request のベース ブランチ名ではなく) pull request の head ブランチ名に基づいてジョブを実行するには、条件で github.head_ref コンテキストを使います。 たとえば、このワークフローは pull request が開かれるたびに実行されますが、pull request の head が run_if で始まる名前のブランチである場合にのみ releases/ ジョブが実行されます。

on:
  pull_request_target:
    types:
      - opened
jobs:
  run_if:
    if: startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

pull request で変更されたファイルに基づいて pull_request_target ワークフローを実行する

          `paths` または `paths-ignore` フィルターを使って、pull request によって特定のファイルが変更されたときに実行するようにワークフローを構成することもできます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。

たとえば、このワークフローは、pull request に JavaScript ファイル (.js) への変更が含まれているときに実行されます。

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

pull request がマージされたときに pull_request_target ワークフローが実行されるようにする

pull request がマージされると、pull request は自動的に閉じられます。 pull request のマージ時にワークフローを実行するには、イベントの pull_request_target 値を検査する条件とともにイベントの種類 closed``merged を使います。 たとえば、次のワークフローは、pull request が閉じるたびに実行されます。 if_merged ジョブは、pull request もマージされた場合にのみ実行されます。

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

push

コミットまたはタグをプッシュするとき、またはテンプレートからリポジトリを作成するときにワークフローを実行します。

たとえば、push イベントが発生したときにワークフローを実行できます。

on:
  push

          `push` Webhook イベントによってワークフローの実行がトリガーされると、Actions UI の [pushed by] フィールドには、作成者またはコミットしたユーザーではなく、プッシュしたユーザーのアカウントが表示されます。 一方、デプロイ キーによる SSH 認証を使って変更がリポジトリにプッシュされた場合は、[プッシュ元] フィールドは、デプロイ キーがリポジトリに追加されたときにそれを確認したリポジトリ管理者になります。

特定のブランチへのプッシュが発生した場合にのみワークフローを実行する

          `branches` または `branches-ignore` フィルターを使って、特定のブランチがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)」をご覧ください。

たとえば、このワークフローは、main か、releases/ で始まるブランチに誰かがプッシュしたときに実行されます。

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

特定のタグのプッシュが発生した場合にのみワークフローを実行する

          `tags` または `tags-ignore` フィルターを使って、特定のタグがプッシュされたときにのみ実行するようにワークフローを構成できます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore)」をご覧ください。

たとえば、このワークフローは、v1. で始まるタグを誰かがプッシュしたときに実行されます。

on:
  push:
    tags:
      - v1.**

プッシュが特定のファイルに影響を与える場合にのみワークフローを実行する

          `paths` または `paths-ignore` フィルターを使って、特定のファイルへのプッシュが発生したときに実行するようにワークフローを構成することができます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。

たとえば、このワークフローは、誰かが JavaScript ファイル (.js) に変更をプッシュしたときに実行されます。

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

registry_package

jobs:
    job_name:
        if: $true

GitHub Packages に関連するアクティビティがリポジトリで発生したときにワークフローを実行します。 詳しくは、「GitHub Packages のドキュメント」をご覧ください。

たとえば、新しいパッケージのバージョンが published になったらワークフローを実行できます。

on:
  registry_package:
    types: [published]

release

          `prereleased` の種類は、ドラフト リリースから公開されたプレリリースではトリガーされませんが、`published` の種類はトリガーされます。 "安定した"_と_プレリリースのパブリッシュ時にワークフローを実行する場合は、`published` と `released` ではなく `prereleased` をサブスクライブします。

リポジトリのリリース アクティビティが発生したときにワークフローを実行します。 リリース API については、GraphQL API ドキュメントの「オブジェクト」または REST API ドキュメントの「リリースとリリース資産の REST API エンドポイント」をご覧ください。

たとえば、リリースが published だったときにワークフローを実行できます。

on:
  release:
    types: [published]

repository_dispatch

          [repository_dispatch](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) | カスタム | デフォルトブランチの直近のコミット | デフォルトブランチ |

GitHub の外部で発生したアクティビティに対してワークフローをトリガーしたい場合は、GitHub API を使って、repository_dispatch と呼ばれる Webhook イベントをトリガーできます。 詳しくは、「リポジトリの REST API エンドポイント」をご覧ください。

          `repository_dispatch` イベントを作成する要求を行う場合は、アクティビティの種類を説明する `event_type` を指定する必要があります。 既定では、`repository_dispatch` のすべてのアクティビティの種類によってワークフローの実行がトリガーされます。 
          `types` キーワードを使うと、`event_type` Webhook ペイロードで特定の `repository_dispatch` 値が送信されたときに実行されるワークフローを制限できます。

on:
  repository_dispatch:
    types: [test_result]

          `event_type` の値は 100 文字に制限されています。

          `client_payload` パラメーターを使って送信するすべてのデータは、ワークフローの `github.event` コンテキストで使用できます。 たとえば、リポジトリ ディスパッチ イベントを作成するときにこの要求本文を送信する場合は、次のようになります。

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

その後、次のようにワークフロー内のペイロードにアクセスできます。

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

schedule

          `schedule` イベントを使うと、スケジュールした時刻にワークフローをトリガーできます。


          **Example:**

 on:
   schedule:
     - cron: "15 4,5 * * *"

データ 再利用可能.repositories.actions-スケジュール済み-ワークフロー-例 %}

          [crontab guru](https://crontab.guru/) を使うと、cron 構文の生成および実行時間の確認に役立ちます。 作業の開始に役立つ [crontab guru のサンプル](https://crontab.guru/examples.html)一覧もあります。

スケジュールされたワークフローの actor

特定のリポジトリ イベントによって、ワークフローに関連付けられている actor が変更されます。 たとえば、リポジトリの既定のブランチを変更する (それによってスケジュールされたワークフローを実行するブランチが変更される) ユーザーは、それらのスケジュールされたワークフローの actor になります。

スケジュールされたワークフローが非アクティブ化されている場合、リポジトリに対して write アクセス許可を持つユーザーがワークフローの cron スケジュールを変更するコミットを行うと、ワークフローは再アクティブ化され、そのユーザーはすべてのワークフロー実行に関連付けられた actor になります。

ワークフロー内のクーロン構文を最後に修正したユーザには、スケジュールされたワークフローの通知が送られます。 詳しくは、「ワークフロー実行の通知」をご覧ください。

status

Git コミットの状態が変更されたときにワークフローを実行します。 たとえば、コミットは error、failure、pending、または success としてマークできます。 状態の変更に関する詳細を指定する場合は、check_run イベントを使用できます。 コミット状態 API については、GraphQL API ドキュメントの「オブジェクト」または「コミット用の REST API エンドポイント」をご覧ください。

たとえば、status イベントが発生したときにワークフローを実行できます。

on:
  status

新しいコミット状態に基づいてワークフローでジョブを実行する場合は、github.event.state コンテキストを使用できます。 たとえば、次のワークフローはコミット状態が変更されたときにトリガーされますが、if_error_or_failure ジョブは新しいコミット状態が error または failureにのみ実行されます。

on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION

watch

ワークフローのリポジトリが Star 付きになったときにワークフローを実行します。 pull request API については、GraphQL API ドキュメントの「変異」または「星付け用 REST API エンドポイント」をご覧ください。

たとえば、誰かがリポジトリに star を付けたときにワークフローを実行できます。これは、Watch イベントのアクティビティの種類 started です。

on:
  watch:
    types: [started]

workflow_call

          `workflow_call` は、別のワークフローからワークフローを呼び出すことができることを示すために使用されます。 
          `workflow_call` イベントを使ってワークフローがトリガーされると、呼び出し対象のワークフロー内のイベント ペイロードは、呼び出し元ワークフローからの同じイベント ペイロードになります。 詳しくは、「[AUTOTITLE](/actions/using-workflows/reusing-workflows)」を参照してください。

次の例では、別のワークフローから呼び出された場合にのみワークフローを実行します。

on: workflow_call

workflow_dispatch

          [workflow_dispatch](/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch) | 該当なし | 
          `GITHUB_REF` ブランチまたはタグでの直近のコミット | ディスパッチを受信したブランチまたはタグ |

ワークフローを手動でトリガーできるようにするには、workflow_dispatch イベントを構成する必要があります。 GitHub API、GitHub CLI、または GitHub UI を使って、ワークフローの実行を手動でトリガーできます。 詳しくは、「ワークフローの手動実行」をご覧ください。

on: workflow_dispatch

入力の提供

カスタム定義の入力プロパティ、デフォルトの入力値、イベントに必要な入力をワークフローで直接設定できます。 イベントをトリガーするときは、ref と任意の inputs を指定できます。 ワークフローを実行すると、inputs コンテキスト内の入力値にアクセスできます。 詳しくは、「コンテキスト リファレンス」をご覧ください。

{ユーザー定義の GitHub Actions の入力と GitHub イベントによって提供される入力の違い}

この例では、logLevel、tags、environment という名前の入力が定義されています。 これらの入力の値は、ワークフローに実行時に渡します。 次に、このワークフローでは、inputs.logLevel、inputs.tags、inputs.environment のコンテキスト プロパティを使って、値をログに出力します。

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

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

ブラウザーからこのワークフローを実行する場合は、ワークフローを実行する前に、必要な入力の値を手動で入力する必要があります。

スクリプトからワークフローを実行するとき、または GitHub CLI を使って、入力を渡すこともできます。 次に例を示します。

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

詳しくは、「ワークフローの手動実行」で GitHub CLI の情報をご覧ください。

workflow_run

このイベントは、ワークフローの実行が要求されたか完了したときに発生します。 これで、別のワークフローの実行または完了に基づいてワークフローを実行できます。 workflow_run イベントによって開始されたワークフローでは、前のワークフローではできなかった場合でも、シークレットや書き込みトークンにアクセスできます。 これは、以前のワークフローが意図的に権限を与えられていない場合に役立ちますが、権限を与えられたアクションは後のワークフローで行わなければなりません。

この例では、ワークフローは個別の「Run Tests」ワークフローの完了後に実行されるように設定されています。

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

          `workflows` イベントに複数の `workflow_run` を指定した場合、実行する必要があるワークフローは 1 つだけです。 たとえば、次のトリガーを持つワークフローは、"ステージング" ワークフローまたは "ラボ" ワークフローが完了するたびに実行されます。

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

別のワークフローの結果に基づいてワークフローを実行する

ワークフロー実行は、前のワークフローの結果に関係なくトリガーされます。 トリガーするワークフローの結果に基づいてジョブまたはステップを実行する場合は、github.event.workflow_run.conclusion プロパティで条件を使用できます。 たとえば、このワークフローは、"Build" という名前のワークフローが完了するたびに実行されますが、on-success ジョブは、"Build" ワークフローが成功した場合にのみ実行され、on-failure ジョブは "Build" ワークフローが失敗した場合にのみ実行されます。

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

ブランチに基づいて実行するワークフローを制限する

          `branches` または `branches-ignore` フィルターを使って、ワークフローをトリガーするために、トリガーするワークフローで実行する必要があるブランチを指定できます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_runbranchesbranches-ignore)」をご覧ください。 たとえば、次のトリガーを持つワークフローは、名前が `Build` のブランチで `canary` という名前のワークフローが実行される場合にのみ実行されます。

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

トリガーするワークフローからデータを使う

ワークフローをトリガーしたワークフローに対応する workflow_runイベント ペイロードにアクセスできます。 たとえば、トリガーするワークフローによって成果物が生成される場合、workflow_run イベントでトリガーされたワークフローからこれらの成果物にアクセスできます。

次のワークフローでは、データを成果物としてアップロードします。 (この簡略化された例では、データは pull request 番号です)。

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v4
        with:
          name: pr_number
          path: pr/

上記のワークフローの実行が完了すると、次のワークフローの実行がトリガーされます。 次のワークフローでは、github.event.workflow_run コンテキストと GitHub REST API を使って、上記のワークフローによってアップロードされた成果物をダウンロードし、ダウンロードした成果物を解凍して、番号が成果物としてアップロードされた pull request についてコメントします。

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v8
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            if (!fs.existsSync(temp)){
              fs.mkdirSync(temp);
            }
            fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip "${{ runner.temp }}/artifacts/pr_number.zip" -d "${{ runner.temp }}/artifacts"

      - name: 'Comment on PR'
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            const issue_number = Number(fs.readFileSync(path.join(temp, 'pr_number')));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });