ステータスチェックは、リポジトリにプッシュをするたびに実行される継続的インテグレーションのビルドのような、外部のプロセスに基づいています。 pull request 中の個々のコミットの隣に、ステータスチェックの pending、passing、failing などのステータスが表示されます。
書き込み権限があるユーザまたはインテグレーションなら誰でも、リポジトリのステータスチェックを任意のステータスに設定できます。
ブランチへの最後のコミットの全体的なステータスは、リポジトリのブランチページあるいはリポジトリのプルリクエストのリストで見ることができます。
リポジトリでステータスチェックが要求されているなら、必須のステータスチェックをパスしてからでないと保護されたブランチにあなたのブランチはマージできません。 詳しくは、「保護されたブランチについて」を参照してください。
GitHub Enterprise Cloudでのステータスチェックの種類
GitHub Enterprise Cloud のステータスチェックには 2 種類あります。
- チェック
- ステータス
チェックは、行のアノテーション、より詳細なメッセージを提供するという点でステータスとは異なっており、GitHub App でのみ利用できます。
Organization オーナー、およびリポジトリにプッシュアクセスを持つユーザは、GitHub Enterprise Cloud の API でチェックおよびステータスを作成できます。 詳細については、「チェック」および「コミット」を参照してください。
チェック
リポジトリでチェックがセットアップされている場合、pull request には [チェック] タブがあり、そこからステータスチェックからの詳細なビルドのアウトプットを見て、失敗したチェックを再実行できます。
注釈: リポジトリの状態ではなく、チェックを設定した場合にのみ、 [チェック] タブに pull request が設定されます。
コミットの特定の行でチェックが失敗している場合、その失敗、警告、注意に関する詳細が pull request の [ファイル] タブの関連するコードの横に表示されます。
[チェック] タブの下のコミットドロップダウンメニューを使って、pull request 中のさまざまなコミットのチェックのサマリー間を移動することができます。
個々のコミットに関するチェックのスキップとリクエスト
リポジトリがプッシュに対して自動的にチェックをリクエストするように設定されている場合、プッシュする個々のコミットについてチェックをスキップできます。 リポジトリがプッシュに対して自動的にチェックをリクエストするよう設定されていない場合、プッシュする個々のコミットについてチェックをリクエストできます。 これらの設定について詳しくは、「チェック」を参照してください。
コミット メッセージにコマンドを含めることで、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"
状態チェックの保持
GitHub.com では、チェック データが 400 日間保持されます。 400 日後、データはアーカイブされます。
アーカイブされているチェック データについては、コミット用のチェック全部の状態を表すロールアップ コミット ステータスが表示されます。 必須であり、アーカイブされているチェックと pull request をマージするには、チェックを再実行する必要があります。