ステータスチェックは、リポジトリにプッシュをするたびに実行される継続的インテグレーションのビルドのような、外部のプロセスに基づいています。 pull request 中の個々のコミットの隣に、ステータスチェックの pending、passing、failing などのステータスが表示されます。
書き込み権限があるユーザまたはインテグレーションなら誰でも、リポジトリのステータスチェックを任意のステータスに設定できます。
ブランチへの最後のコミットの全体的なステータスは、リポジトリのブランチページあるいはリポジトリのプルリクエストのリストで見ることができます。
リポジトリでステータスチェックが要求されているなら、必須のステータスチェックをパスしてからでないと保護されたブランチにあなたのブランチはマージできません。 詳しくは、「保護されたブランチについて」をご覧ください。
Note
スキップされたジョブは、その状態が "成功" として報告されます。 必要なチェックであっても、pull request のマージを妨げるものではありません。
GitHub でのステータス チェックの種類
GitHub のステータス チェックには 2 種類あります。
- チェック
- コミットのステータス
_チェック_は、行のアノテーション、より詳細なメッセージを提供するという点で_コミット状態_とは異なっており、GitHub App でのみ利用できます。
Note
GitHub Actions は、ワークフローの実行時にコミット状態ではなく、チェックを生成します。
Organization 所有者と、リポジトリに対してプッシュ アクセス権を持つユーザーは、GitHub の API を使ってチェックとコミット状態を作成できます。 詳細については、「チェック用 REST API エンドポイント」および「コミットのステータス用の REST API エンドポイント」を参照してください。
チェック
リポジトリで_チェック_がセットアップされている場合、pull request には [チェック] Tab があり、そこからチェックからの詳細なビルドの出力を見て、失敗したチェックを再実行できます。
Note
リポジトリに対して "コミット状態" ではなく "チェック" を設定した場合、[Checks] タブには pull request のみが表示されます。****____
コミットの特定の行でチェックが失敗している場合、その失敗、警告、注意に関する詳細が pull request の [ファイル] タブの関連するコードの横に表示されます。
[チェック] タブの下のコミットドロップダウンメニューを使って、pull request 中のさまざまなコミットのチェックのサマリー間を移動することができます。
個々のコミットに関するチェックのスキップとリクエスト
リポジトリがプッシュに対して自動的にチェックをリクエストするように設定されている場合、プッシュする個々のコミットについてチェックをスキップできます。 リポジトリがプッシュに対して自動的にチェックをリクエストするよう設定されて_いない_場合、プッシュする個々のコミットについてチェックをリクエストできます。 これらの設定の詳細については、「チェック スイート用 REST API エンドポイント」を参照してください。
コミット メッセージにコマンドを含めることで、push
と pull_request
イベントによってトリガーされるワークフロー実行をスキップすることもできます。 詳細については、「ワークフロー実行をスキップする」を参照してください
また、コミットに対する "すべて" のチェックをスキップもしくはリクエストするには、以下のトレーラー行のいずれかをコミット メッセージの末尾に追加します。__
-
コミットの_チェックをスキップ_には、コミットメッセージと変更の短く意味のある説明を入力してください。 コミットの説明の後、終了引用符の前に、2 つの空の行を追加してから
skip-checks: true
を追加します。$ git commit -m "Update README > > skip-checks: true"
-
コミットのチェックを_リクエスト_するには、コミットメッセージと変更の短く意味のある説明を入力してください。 コミットの説明の後、終了引用符の前に、2 つの空の行を追加してから
request-checks: true
を追加します。$ git commit -m "Refactor usability tests > > request-checks: true"
既定では、Git は連続する改行を自動的に削除します。 コミット メッセージを入力したとおりのままにするには、コミットで--cleanup=verbatim
オプションを使用します。 詳細については、Git ドキュメントにある「--cleanup=<mode>
」を参照してください。
状態と結論をチェックする
チェックにはさまざまな状態があります。 状態は、チェックが作成されてから完了するまでのチェックの状態を表します。 一部の状態は手動で設定できず、GitHub Actions 用に予約されています。 チェックの状態が completed
の場合は、結論があります。 結論では、チェックの結果が説明されます。 考えられるすべてのチェックの状態と結論を以下に示します。
状態 | 説明 | GitHub Actions のみ? |
---|---|---|
completed | チェック実行が完了し、結論が得られました (下記参照)。 | いいえ |
expected | チェック実行は状態の報告待ちです。 | はい |
failure | チェック実行に失敗しました。 | いいえ |
in_progress | チェック実行が進行中です。 | いいえ |
pending | チェック実行はキューの先頭にありますが、グループベースのコンカレンシー制限に達しています。 | はい |
queued | チェック実行がキューに登録されました。 | いいえ |
requested | チェック実行は作成されましたが、キューに登録されていません。 | はい |
startup_failure | 起動時にチェック スイートが失敗しました。 この状態はチェック実行には適用されません。 | はい |
waiting | 配置保護規則が満たされるまで、チェック実行は待機中です。 | はい |
まとめ | 説明 |
---|---|
action_required | チェック実行により、補完時に必要なアクションが提供されました。 詳しくは、「REST API を使用してチェックを操作する」をご覧ください。 |
cancelled | チェック実行が完了する前に取り消されました。 |
failure | チェック実行に失敗しました。 |
neutral | チェック実行はニュートラルな結果で完了しました。 これは、GitHub Actions の依存関係チェックの成功として扱われます。 |
skipped | チェック実行はスキップされました。 これは、GitHub Actions の依存関係チェックの成功として扱われます。 |
stale | チェック実行に時間がかかりすぎたため、GitHub によって古いとマークされました。 |
success | チェック実行は正常に完了しました。 |
timed_out | チェック実行はタイムアウトしました。 |
チェック の保持
必須であり、アーカイブされているチェックと pull request をマージするには、チェックを再実行する必要があります。