ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。
ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。
ワークフローイベントを設定する
on ワークフロー構文を使用して、1 つ以上のイベントに対して実行するようにワークフローを設定できます。 詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。
単一のイベントを使用する例
# リポジトリ内の任意のブランチにコードがプッシュされたときにトリガーされる
on: push
イベントのリストを使用する例
# プッシュもしくはPull Requestイベントでワークフローをトリガーする
on: [push, pull_request]
アクティビティの種類もしくは設定を伴う複数のイベントを使用する例
イベントに対してアクティビティの種類もしくは設定を指定する必要がある場合、それぞれのイベントを個別に設定しなければなりません。 設定を持たないイベントも含め、すべてのイベントにはコロン (:)を追加しなければなりません。
on:
# プッシュもしくはPull Requestでワークフローをトリガーする
# ただしメインブランチの場合のみ
push:
branches:
- main
pull_request:
branches:
- main
# page_buildとリリース作成イベントでもトリガーする
page_build:
release:
types: # この設定は上記のpage_buildイベントには影響しない
- created
ノート: GITHUB_TOKENを使って新しいワークフローの実行をトリガーすることはできません。 詳しい情報については「個人アクセストークンを使った新しいワークフローのトリガー」を参照してください。
ワークフローの実行がトリガーされるには、以下のステップが生じます。
-
リポジトリでイベントが発生し、結果のイベントにはコミット SHA と Git ref が関連付けられます。
-
リポジトリ内の関連づけられたコミットSHAもしくはGit refにおける
.github/workflowsディレクトリ内でワークフローファイルが検索される。 ワークフローファイルは、コミットSHAあるいはGit refを考慮した上で存在していなければなりません。たとえば、イベントが特定のリポジトリブランチで発生したなら、ワークフローファイルはそのブランチ上でリポジトリ内に存在しなければなりません。
-
そのコミットSHA及びGit refのワークフローファイルが調べられ、トリガーを起こしたイベントにマッチする
on:の値を持つワークフローについて新しい実行がトリガーされる。ワークフローの実行は、イベントをトリガーしたのと同じコミットSHA及びGit refにあるリポジトリのコード上で実行されます。 ワークフローを実行すると、GitHub Enterprise Server はランナー環境において
GITHUB_SHA(コミット SHA) およびGITHUB_REF(Git ref) 環境変数を設定します。 詳しい情報については、「環境変数の利用」を参照してください。
スケジュールしたイベント
schedule イベントを使用すると、スケジュールされた時間にワークフローをトリガーできます。
ノート: scheduleイベントは、GitHub Actionsのワークフローの実行による高負荷の間、遅延させられることがあります。 高負荷の時間帯には、毎時の開始時点が含まれます。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。
スケジュール
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
| n/a | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
POSIX クーロン構文を使用して、特定の UTC 時間にワークフローを実行できるようスケジュール設定できます。 スケジュールしたワークフローは、デフォルトまたはベースブランチの直近のコミットで実行されます。 スケジュールされたワークフローを実行できる最短の間隔は、5 分ごとに 1 回です。
この例では、ワークフローは毎日UTCの5:30と17:30にトリガーされます。
on:
schedule:
# *はYAMLにおける特殊文字なので、この文字列はクオートしなければならない
- cron: '30 5,17 * * *'
クーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。
┌───────────── 分 (0 - 59)
│ ┌───────────── 時間 (0 - 23)
│ │ ┌───────────── 日 (1 - 31)
│ │ │ ┌───────────── 月 (1 - 12 または JAN-DEC)
│ │ │ │ ┌───────────── 曜日 (0 - 6 または SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
5 つのフィールドいずれにおいても、以下の演算子を使用できます:
| 演算子 | 説明 | サンプル |
|---|---|---|
| * | 任意の値 | * * * * * 毎日、毎分実行します。 |
| , | 値リストの区切り文字 | 2,10 4,5 * * * 毎日、午前 4 時および午前 5 時の、2 分および 10 分に実行します。 |
| - | 値の範囲 | 0 4-6 * * * 午前 4 時、5 時、および 6 時の、0 分に実行します。 |
| / | ステップ値 | 20/15 * * * * 20 分から 59 分までの間で、15 分おきに実行します (20 分、35 分、50 分)。 |
注釈: GitHub Actions は、非標準的構文 (@yearly、@monthly、@weekly、@daily、@hourly、@reboot) をサポートしていません。
crontab guru を使うと、クーロン構文の生成および実行時間の確認に役立ちます。 また、クーロン構文の生成を支援するため、crontab guru のサンプルリストもあります。
ワークフロー内のクーロン構文を最後に修正したユーザには、スケジュールされたワークフローの通知が送られます。 詳しい情報については「ワークフローの実行の通知」を参照してください。
手動イベント
ワークフローの実行を手動でトリガーできます。 リポジトリ内の特定のワークフローをトリガーするには、workflow_dispatch イベントを使用します。 リポジトリで複数のワークフローをトリガーし、カスタムイベントとイベントタイプを作成するには、repository_dispatch イベントを使用します。
workflow_dispatch
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
| workflow_dispatch | n/a | GITHUB_REF ブランチ上の直近のコミット | ディスパッチを受信したブランチ |
カスタム定義の入力プロパティ、デフォルトの入力値、イベントに必要な入力をワークフローで直接設定できます。 ワークフローが実行されると、 github.event.inputs コンテキスト内の入力値にアクセスできます。 詳細については、「コンテキスト」を参照してください。
You can manually trigger a workflow run using the GitHub API and from GitHub. 詳しい情報については、「ワークフローを手動で実行する」を参照してください。
GitHub でイベントをトリガーすると、GitHub で ref と inputs を直接入力できます。 詳しい情報については、「アクションで入力と出力を使用する」を参照してください。
REST API を使用してカスタム workflow_dispatch webhook イベントをトリガーするには、POST リクエストを GitHub API エンドポイントに送信し、ref および必要な inputs を入力する必要があります。 詳細については、「ワークフローディスパッチイベントの作成」REST API エンドポイントを参照してください。
サンプル
workflow_dispatchイベントを使うには、GitHub Actionsのワークフローファイル中にトリガーとして含めなければなりません。 以下の例では、手動でトリガーされた場合にのみワークフローが実行されます。
on: workflow_dispatch
ワークフロー設定の例
この例では、 nameとhomeの入力を定義し、github.event.inputs.nameおよびgithub.event.inputs.homeコンテキストを使用してそれらを出力します。 homeが提供されなければ、デフォルト値の'The Octoverse'が出力されます。
name: Manually triggered workflow
on:
workflow_dispatch:
inputs:
name:
description: 'Person to greet'
required: true
default: 'Mona the Octocat'
home:
description: 'location'
required: false
default: 'The Octoverse'
jobs:
say_hello:
runs-on: ubuntu-latest
steps:
- run: |
echo "Hello ${{ github.event.inputs.name }}!"
echo "- in ${{ github.event.inputs.home }}!"
repository_dispatch
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
| repository_dispatch | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
GitHub Enterprise Server の外部で生じるアクティビティのためにワークフローをトリガーしたい場合、GitHub API を使って、repository_dispatch と呼ばれる webhook イベントをトリガーできます。 詳細については、「リポジトリディスパッチ イベントの作成」を参照してください。
カスタム repository_dispatch webhook イベントをトリガーするには、GitHub Enterprise Server API エンドポイントに POST リクエストを送信して、アクティビティのタイプを説明する event_type 名を提供する必要があります。 ワークフローの実行をトリガーするには、repository_dispatch イベントを使用するようワークフローを設定する必要もあります。
サンプル
デフォルトでは、すべてのevent_typesがワークフローの実行をトリガーします。 特定のevent_typeの値がrepository_dispatch webhookのペイロード内で送信された時にのみワークフローが実行されるように制限できます。 リポジトリのディスパッチイベントを生成する際に、repository_dispatchペイロード内で送信されるイベントの種類を定義します。
on:
repository_dispatch:
types: [opened, deleted]
webhook イベント
webhook イベントが GitHub Enterprise Server で生成されたときに実行されるようにワークフローを設定できます イベントによっては、そのイベントをトリガーするアクティビティタイプが 複数あります。 イベントをトリガーするアクティビティタイプが複数ある場合は、ワークフローの実行をトリガーするアクティビティタイプを指定できます。 詳しい情報については、「webhook」を参照してください。
すべての webhook イベントがワークフローをトリガーするわけではありません。 使用可能な webhook イベントとそのペイロードの完全なリストについては、「webhook イベントとペイロード」を参照してください。
check_run
check_run イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「チェック実行」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
check_run | - created- rerequested- completed | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、チェック実行が rerequested または completed であったときにワークフローを実行できます。
on:
check_run:
types: [rerequested, completed]
check_suite
check_suite イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「チェックスイート」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
ノート: 再帰的なワークフローを避けるために、このイベントはGitHub Actionsによってチェックスイートが生成されている場合にはワークフローをトリガーしません。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
check_suite | - completed- requested- rerequested | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、チェック実行が rerequested または completed だったときにワークフローを実行する例は、次のとおりです。
on:
check_suite:
types: [rerequested, completed]
create
誰かがブランチまたはタグを作成し、それによって create イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リファレンスの作成」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
create | n/a | 直近でブランチまたはタグが作成されたコミット | 作成されたブランチまたはタグ |
たとえば、create イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
create
delete
誰かがブランチまたはタグを作成し、それによって delete イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リファレンスの削除」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
delete | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、delete イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
delete
deployment
誰かがデプロイメントを作成し、それによって deployment イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「デプロイメント」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
deployment | n/a | デプロイされるコミット | デプロイされるブランチまたはタグ (コミットの場合は空) |
たとえば、deployment イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
deployment
deployment_status
サードパーティプロバイダーがデプロイメントステータスを提供し、それによって deployment_status イベントがトリガーされるときにワークフローを実行します。 コミット SHA 付きで作成されたデプロイメントには Git ref がない場合があります。 REST API の詳細については、「デプロイメントステータスの作成」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
deployment_status | n/a | デプロイされるコミット | デプロイされるブランチまたはタグ (コミットの場合は空) |
たとえば、deployment_status イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
deployment_status
注釈: デプロイメントステータスの状態が inactive に設定されている場合、webhook イベントは作成されません。
フォーク
誰かがリポジトリをフォークし、それによって deployment_status イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「フォークの作成」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
フォーク | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、fork イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
fork
gollum
誰かが Wiki ページを作成または更新し、それによって gollum イベントがトリガーされるときにワークフローを実行します。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
gollum | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、gollum イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
gollum
issue_comment
issue_comment イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Issue コメント」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
issue_comment | - created- edited- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、Issue コメントが created または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
issue_comment:
types: [created, deleted]
issue_commentイベントは、IssueやPull Requestにコメントされたときに生じます。 issue_commentイベントがIssueで生じたのかPull Requestで生じたのかを判断するには、イベントのペイロードのissue.pull_request属性をチェックして、それをジョブをスキップする条件として利用できます。
たとえば、コメントイベントがPull Requestで生じたときにpr_commentedを実行し、コメントイベントがIssueで生じたときにissue_commentedジョブを実行するようにできます。
on: issue_comment
jobs:
pr_commented:
# このジョブはプルリクエストコメントに対してのみ実行されます
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on PR #${{ github.event.issue.number }}"
issue_commented:
# このジョブは Issue comment に対してのみ実行されます
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo "Comment on issue #${{ github.event.issue.number }}"
issues
Issue イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Issue」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
issues | - opened- edited- deleted- transferred- pinned- unpinned- closed- reopened- assigned- unassigned- labeled- unlabeled- locked- unlocked- milestoned- demilestoned | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、Issue が opened、edited、または milestoned だったときにワークフローを実行する例は、次のとおりです。
on:
issues:
types: [opened, edited, milestoned]
ラベル
label イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「ラベル」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
ラベル | - created- edited- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、ラベルが created または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
label:
types: [created, deleted]
マイルストーン
milestone イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「マイルストーン」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
マイルストーン | - created- closed- opened- edited- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえばマイルストーンがopenedあるいはdeletedになったときにワークフローを実行できます。
on:
milestone:
types: [opened, deleted]
page_build
誰かが GitHub Enterprise Server ページ対応のブランチを作成し、それによって page_build イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「ページ」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
page_build | n/a | デフォルトブランチの直近のコミット | n/a |
たとえば、page_build イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
page_build
project
project イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクト」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
project | - created- updated- closed- reopened- edited- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プロジェクトが created または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
project:
types: [created, deleted]
project_card
project_card イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクトカード」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
project_card | - created- moved- converted to an issue- edited- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プロジェクトカードが opened または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
project_card:
types: [created, deleted]
project_column
project_column イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「プロジェクト列」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
project_column | - created- updated- moved- deleted | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プロジェクト列が created または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
project_column:
types: [created, deleted]
public
誰かがプライベートリポジトリをパブリックにし、それによって public イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「リポジトリの編集」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
public | n/a | デフォルトブランチの直近のコミット | デフォルトブランチ |
たとえば、public イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
public
pull_request
pull_request イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see "Pull requests."
ノート:
- By default, a workflow only runs when a
pull_request's activity type isopened,synchronize, orreopened. 他のアクティビティタイプについてもワークフローをトリガーするには、typesキーワードを使用してください。 - Workflows will not run on
pull_requestactivity if the pull request has a merge conflict. The merge conflict must be resolved first.
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
pull_request | - assigned- unassigned- labeled- unlabeled- opened- edited- closed- reopened- synchronize- converted_to_draft- ready_for_review- locked- unlocked - review_requested - review_request_removed | GITHUB_REF ブランチ上の直近のマージコミット | PR マージブランチ refs/pull/:prNumber/merge |
デフォルトのアクティビティタイプを拡大または制限するには、types キーワードを使用します。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プルリクエストが assigned、opened、synchronize、または reopened だったときにワークフローを実行できます。
on:
pull_request:
types: [assigned, opened, synchronize, reopened]
フォークしたリポジトリのPull Requestイベント
ノート： フォークされたリポジトリでPull Requestをオープンした場合には、プライベートのベースリポジトリではワークフローは実行されません。
フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。
GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
ノート: DependabotのPull Requestによってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。
pull_request_review
pull_request_review イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see "Pull request reviews."
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
pull_request_review | - submitted- edited- dismissed | GITHUB_REF ブランチ上の直近のマージコミット | PR マージブランチ refs/pull/:prNumber/merge |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プルリクエストレビューが edited または dismissed だったときにワークフローを実行する例は、次のとおりです。
on:
pull_request_review:
types: [edited, dismissed]
フォークしたリポジトリのPull Requestイベント
ノート： フォークされたリポジトリでPull Requestをオープンした場合には、プライベートのベースリポジトリではワークフローは実行されません。
フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。
GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
ノート: DependabotのPull Requestによってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。
pull_request_review_comment
プルリクエストの統合 diff へのコメントが変更され、それによって pull_request_review_comment イベントがトリガーされるときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 For information about the REST API, see Review comments.
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
pull_request_review_comment | - created- edited- deleted | GITHUB_REF ブランチ上の直近のマージコミット | PR マージブランチ refs/pull/:prNumber/merge |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、プルリクエストレビューコメントが created または deleted だったときにワークフローを実行する例は、次のとおりです。
on:
pull_request_review_comment:
types: [created, deleted]
フォークしたリポジトリのPull Requestイベント
ノート： フォークされたリポジトリでPull Requestをオープンした場合には、プライベートのベースリポジトリではワークフローは実行されません。
フォークされたリポジトリからベースリポジトリに対するPull Requestを作成した場合、GitHubはベースリポジトリに対してpull_requestイベントを送り、フォークされたリポジトリではPull Requestイベントは生じません。
デフォルトでは、フォークされたリポジトリではワークフローは実行されません。 フォークされたリポジトリの ActionsタブでGitHub Actionsを有効化しなければなりません。
GITHUB_TOKENを除き、フォークしたリポジトリからワークフローがトリガーされた場合、シークレットはランナーに渡されません。 フォークされたリポジトリ内のGITHUB_TOKENの権限は読み取りのみです。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
ノート: DependabotのPull Requestによってトリガーされたワークフローは、フォークされたリポジトリからのもののように扱われ、これらの制約を受けます。
プッシュ
ノート： GitHub Actionsが利用できるwebhookのペイロードには、commitオブジェクト中のadded、removed、modified属性は含まれません。 完全なcommitオブジェクトは、REST APIを使って取得できます。 詳しい情報については、「1つのコミットの取得」を参照してください。
誰かがリポジトリブランチにプッシュし、それによって push イベントがトリガーされるときにワークフローを実行します。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
プッシュ | n/a | プッシュされたコミット、ただし (デフォルトブランチの際に) ブランチを削除する場合を除く | 更新された ref |
たとえば、push イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
push
registry_package
パッケージがpublishedもしくはupdatedされるとワークフローを実行します。 詳しい情報については「GitHub Packagesでのパッケージ管理」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
registry_package | - published- updated | 公開されたパッケージのコミット | 公開されたパッケージのブランチもしくはタグ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、パッケージがpublishedされたときにワークフローを実行できます。
on:
registry_package:
types: [published]
リリース
注釈: release イベントは、ドラフトリリースではトリガーされません。
release イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「リリース」を参照してください。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
リリース | - published - unpublished - created - edited - deleted - prereleased- released | リリースのタグが付いた直近のコミット | リリースのタグ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、リリースが published だったときにワークフローを実行する例は、次のとおりです。
on:
release:
types: [published]
注釈: prereleased タイプは、ドラフトリリースから公開されたプレリリースではトリガーされませんが、published タイプはトリガーされます。 安定版およびプレリリースの公開時にワークフローを実行する場合は、released および prereleased ではなく published にサブスクライブします。
ステータス
Git コミットのステータスが変更された、それによって status イベントがトリガーされるときにワークフローを実行します。 REST API の詳細については、「ステータス」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
ステータス | n/a | デフォルトブランチの直近のコミット | n/a |
たとえば、status イベントが発生したときにワークフローを実行する例は、次のとおりです。
on:
status
Watch
watch イベントが発生したときにワークフローを実行します。 このイベントは、2つ以上の種類のアクティビティで起動されます。 REST API の詳細については、「Star を付ける」を参照してください。
ノート: このイベントは、ワークフローファイルがデフォルトブランチにある場合にのみワークフローの実行をトリガーします。
| webhook イベントのペイロード | アクティビティタイプ | GITHUB_SHA | GITHUB_REF |
|---|---|---|---|
Watch | - started | デフォルトブランチの直近のコミット | デフォルトブランチ |
デフォルトでは、すべての種類のアクティビティがワークフローを実行させます。 typesキーワードを使って、ワークフローが実行されるのを特定の種類のアクティビティに限定できます。 詳しい情報については、「GitHub Actionsのワークフロー構文」を参照してください。
たとえば、誰かがリポジトリに Star を付け、それが Watch イベントをトリガーする started アクティブタイプである場合にワークフローを実行する例は、次のとおりです。
on:
watch:
types: [started]
前回のワークフロー実行の結果に基づいて条件付きでワークフロージョブを実行する場合、jobs.<job_id>.if または jobs.<job_id>.steps[*].if 条件を前回の実行の conclusion と組み合わせて使用できます。 例:
on:
workflow_run:
workflows: ["Build"]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
...
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
...
個人アクセストークンを使った新しいワークフローのトリガー
リポジトリのGITHUB_TOKENを使ってGitHub Actions アプリケーションの代わりにタスクを実行した場合、そのGITHUB_TOKENによって生じたイベントは、新たなワークフローの実行を生じさせません。 これによって、予想外の再帰的なワークフローの実行が生じないようになります。 たとえば、ワークフローの実行によってリポジトリのGITHUB_TOKENを使ったコードのプッシュが行われた場合、そのリポジトリにpushイベントが生じた際に実行されるよう設定されたワークフローが含まれていても、新しいワークフローの実行は行われません。 詳しい情報については「GITHUB_TOKENでの認証」を参照してください。
ワークフローの実行からワークフローをトリガーしたい場合意は、個人アクセストークンを使ってイベントをトリガーできます。 個人アクセストークンを作成し、それをシークレットとして保存する必要があります。 GitHub Actionsの利用コストを最小化するために、再帰的あるいは意図しないワークフローの実行が生じないようにしてください。 個人アクセストークンのシークレットとしての保存に関する詳しい情報については「暗号化されたシークレットの作成と保存」を参照してください。