GITHUB_TOKEN について
各ワークフロー ジョブの開始時 GitHub 、ワークフローで使用する一意の GITHUB_TOKEN シークレットが自動的に作成されます。
GITHUB_TOKEN はワークフロー ジョブでの認証に使用できます。
GitHub Actionsを有効にすると、GitHubはリポジトリにGitHub Appをインストールします。
GITHUB_TOKEN シークレットは、GitHub Appインストール アクセス トークンです。 インストール アクセス トークンを使用して、リポジトリにインストールされている GitHub App に代わって認証できます。 このトークンの権限は、ワークフローを含むリポジトリに限定されます。 詳細については、「GitHub Actions のワークフロー構文」を参照してください。
各ジョブが開始される前に、 GitHub はジョブのインストール アクセス トークンをフェッチします。
GITHUB_TOKENは、ジョブが終了するか、最大有効期間が経過すると期限切れになります。
トークンの有効な最大有効期間は、ランナーの種類によって異なります。
- GitHub-hosted runners ジョブの最大実行時間は 6 時間であるため、
GITHUB_TOKENは最大 6 時間有効です。 - セルフホステッド ランナー ジョブの最大実行時間は 5 日です。 ただし、
GITHUB_TOKENはインストール access トークンであるため、更新できるのは最大 24 時間です。 ジョブの実行時間が 24 時間を超える場合は、代わりに personal access token またはその他の認証方法を使用します。
トークンは、github.token コンテキストでも使用できます。 詳細については、「コンテキスト リファレンス」を参照してください。
GITHUB_TOKEN がワークフローの実行をトリガーしたとき
リポジトリの GITHUB_TOKEN を使用してタスクを実行する場合、 GITHUB_TOKEN によってトリガーされるイベントは新しいワークフロー実行を作成しません。ただし、次の例外があります。
workflow_dispatchとrepository_dispatchイベントでは、常にワークフロー実行が作成されます。pull_requestopened、synchronize、またはreopenedアクティビティの種類を含むイベント:GITHUB_TOKENを使用するワークフローがプル要求を作成または更新すると、結果として得られるpull_requestイベントによって、承認が必要な状態でワークフロー実行が作成されます。 プル要求にはマージ ボックスにバナーが表示され、リポジトリへの書き込みアクセス権を持つユーザーは、[実行するワークフローの承認] を選択して 実行を開始できます。 その他のpull_requestアクティビティの種類 (labeled、edited、closedなど) では、ワークフロー実行は作成されません。 これにより、自動化によって作成されたプル要求に対する CI ワークフローの実行を引き続き許可しながら、再帰ワークフローを実行できなくなります。 ワークフロー実行の承認の詳細については、「 フォークからのワークフロー実行の承認」を参照してください。
その他のすべてのイベントでは、この動作により、再帰的なワークフロー実行が誤って作成されるのを防ぐことができます。 たとえば、ワークフロー実行でリポジトリの GITHUB_TOKEN を使用してコードがプッシュされた場合、push イベントの発生時に実行するように構成されたワークフローがリポジトリに含まれている場合でも、新しいワークフローは実行されません。
メモ
ワークフローによって作成されたプル要求からワークフローを実行して承認を必要とせずに実行する必要がある場合は、プル要求の作成時または更新時にGitHub Appするのではなく、personal access tokenインストール アクセス トークンまたはGITHUB_TOKENを使用します。
GITHUB_TOKEN を使う GitHub Actions ワークフローによってプッシュされたコミットでは、GitHub Pages ビルドがトリガーされません。