状態の確認

状態チェックは、コミットがリポジトリに設定された条件を満たしているかどうかを示します。 これらは通常、継続的インテグレーション ビルド、テスト、コード スキャン、デプロイ チェックなどの外部システムによって作成されます。

状態チェックは、レビュー担当者と保守担当者が、プル要求をマージする準備ができているかどうかを理解するのに役立ちます。 チェックは、作業がまだ実行されていること、変更が検証に合格していること、または何かが注意を必要としていることを示すことができます。

書き込み権限を持つ人は誰でも、リポジトリ内のステータスチェックの状態を任意に設定できます。

保護されたブランチに状態チェックが必要な場合は、プル要求をマージする前に、状態チェックに合格する必要があります。 「保護されたブランチについて」を参照してください。

状態チェックの種類 GitHub

GitHubの状態チェックには、次の 2 種類があります。

タイプ	詳細レベル	作成者
チェック	詳細な出力、注釈、およびメッセージ。
GitHub Apps( GitHub Actionsを含む)。
コミットのステータス	コミットのより単純な状態。	外部サービスと統合。

リポジトリへのプッシュ アクセス権を持つ組織の所有者とユーザーは、 GitHubの API を使用してチェックとコミットの状態を作成できます。 「チェック用 REST API エンドポイント」と「コミットのステータス用の REST API エンドポイント」を参照してください。

チェック

チェックには、ビルド ログ、テスト結果、注釈、詳細へのリンクを含めることができます。 pull request の [ チェック ] タブは、実行された検証と、チェックが成功または失敗した理由を理解するのに役立ちます。

チェック が特定の行をポイントすると、プル要求の [ ファイル ] タブにも詳細が表示されます。 これにより、レビュー担当者は、変更されるコードに自動フィードバックを接続できます。

個々のコミットに関するチェックのスキップとリクエスト

一部のリポジトリでは、個々のコミットに対してチェックをスキップまたは要求できます。 これは、チェックが特定の変更に関連しない場合や、チェックが自動的に要求されない場合に役立ちます。

GitHub Actionsワークフローの場合は、コミット メッセージにスキップ命令を含めることで、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用に予約されています。

| 地位 | Description | GitHub Actions だけ。 | | --- | --- | --- | | completed | チェック実行が完了し、結論が得られました (下記参照)。 | いいえ | | expected | チェック実行は状態の報告待ちです。 | はい | | failure | チェック実行に失敗しました。 | いいえ | | in_progress | チェック実行が進行中です。 | いいえ | | pending | チェック実行はキューの先頭にありますが、グループベースのコンカレンシー制限に達しています。 | はい | | queued | チェック実行がキューに登録されました。 | いいえ | | requested | チェックランは作成されましたが、キューに入れられていません。 | はい | | startup_failure | 起動時にチェック スイートが失敗しました。 この状態はチェック実行には適用されません。 | はい | | waiting | 配置保護規則が満たされるまで、チェック実行は待機中です。 | はい |

チェックの状態が completedは、結論があります。 成功した結論は、通常、チェックがマージをブロックしないことを意味します。 失敗、タイムアウト、またはアクションが必要な結論は、通常、プル要求をマージする前に詳細を確認する必要があります。

まとめ	Description
action_required	チェック実行が完了すると、必要なアクションが提供されました。 詳細については、「REST API を使用してチェックを操作する」を参照してください。
cancelled	チェック実行が完了する前に取り消されました。
failure	チェック実行に失敗しました。
neutral	チェック実行はニュートラルな結果で完了しました。 これは、 GitHub Actionsの依存チェックの成功として扱われます。
skipped	チェック実行はスキップされました。 これは、 GitHub Actionsの依存チェックの成功として扱われます。
stale	チェックの実行に時間がかかりすぎるため、 GitHub によって古いマークが付けられました。
success	チェック実行は正常に完了しました。
timed_out	チェック実行はタイムアウトしました。

チェックの保持

GitHub では、チェック データが 400 日間保持されます。 400 日後、データはアーカイブされます。 アーカイブから 10 日後に、データは完全に削除されます。

必須であり、アーカイブされているチェックと pull request をマージするには、チェックを再実行する必要があります。