{"meta":{"title":"状態の確認","intro":"状態チェックでコミットがリポジトリの条件を満たしていることを確認し、プル要求のレビューを支援し、ビルド、テスト、デプロイなどの検証を管理する方法について説明します。","product":"Pull Request","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/pull-requests","title":"Pull Request"},{"href":"/ja/enterprise-cloud@latest/pull-requests/reference","title":"Reference"},{"href":"/ja/enterprise-cloud@latest/pull-requests/reference/status-checks","title":"状態の確認"}],"documentType":"article"},"body":"# 状態の確認\n\n状態チェックでコミットがリポジトリの条件を満たしていることを確認し、プル要求のレビューを支援し、ビルド、テスト、デプロイなどの検証を管理する方法について説明します。\n\n状態チェックは、コミットがリポジトリに設定された条件を満たしているかどうかを示します。 これらは通常、継続的インテグレーション ビルド、テスト、コード スキャン、デプロイ チェックなどの外部システムによって作成されます。\n\n状態チェックは、レビュー担当者と保守担当者が、プル要求をマージする準備ができているかどうかを理解するのに役立ちます。 チェックは、作業がまだ実行されていること、変更が検証に合格していること、または何かが注意を必要としていることを示すことができます。\n\n![コミットと状態の一覧のスクリーンショット。](/assets/images/help/pull_requests/commit-list-statuses.png)\n\n書き込み権限を持つ人は誰でも、リポジトリ内のステータスチェックの状態を任意に設定できます。\n\n保護されたブランチに状態チェックが必要な場合は、プル要求をマージする前に、状態チェックに合格する必要があります。 「[保護されたブランチについて](/ja/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)」を参照してください。\n\n> \\[!NOTE]\n> スキップされたジョブは、その状態が \"成功\" として報告されます。 必要なチェックであっても、pull request のマージを妨げるものではありません。\n\n## 状態チェックの種類 GitHub\n\nGitHubの状態チェックには、次の 2 種類があります。\n\n| タイプ                              | 詳細レベル              | 作成者        |\n| -------------------------------- | ------------------ | ---------- |\n| チェック                             | 詳細な出力、注釈、およびメッセージ。 |            |\n| GitHub Apps( GitHub Actionsを含む)。 |                    |            |\n| コミットのステータス                       | コミットのより単純な状態。      | 外部サービスと統合。 |\n\n> \\[!NOTE]\n> GitHub Actions では、ワークフローの実行時にコミット状態ではなくチェックが生成されます。\n\nリポジトリへのプッシュ アクセス権を持つ組織の所有者とユーザーは、 GitHubの API を使用してチェックとコミットの状態を作成できます。 「[チェック用 REST API エンドポイント](/ja/enterprise-cloud@latest/rest/checks)」と「[コミットのステータス用の REST API エンドポイント](/ja/enterprise-cloud@latest/rest/commits/statuses)」を参照してください。\n\n## チェック\n\nチェックには、ビルド ログ、テスト結果、注釈、詳細へのリンクを含めることができます。 pull request の \\[ **チェック** ] タブは、実行された検証と、チェックが成功または失敗した理由を理解するのに役立ちます。\n\n![pull request の \\[チェック\\] タブのスクリーンショット。 \\[チェック\\] タブとコミットを選ぶドロップダウン メニューが、どちらも濃いオレンジ色の枠線で囲まれています。](/assets/images/help/pull_requests/checks-summary-for-various-commits.png)\n\n> \\[!NOTE]\n> リポジトリの**コミット状態**ではなく \\_、チェック\\_を設定した場合にのみ、\\[*チェック*] タブにプル要求が設定されます。\n\nチェック が特定の行をポイントすると、プル要求の \\[ **ファイル** ] タブにも詳細が表示されます。 これにより、レビュー担当者は、変更されるコードに自動フィードバックを接続できます。\n\n## 個々のコミットに関するチェックのスキップとリクエスト\n\n一部のリポジトリでは、個々のコミットに対してチェックをスキップまたは要求できます。 これは、チェックが特定の変更に関連しない場合や、チェックが自動的に要求されない場合に役立ちます。\n\nGitHub Actionsワークフローの場合は、コミット メッセージにスキップ命令を含めることで、`push`および`pull_request` イベントによってトリガーされるワークフロー実行をスキップできます。 「[ワークフロー実行をスキップする](/ja/enterprise-cloud@latest/actions/how-tos/manage-workflow-runs/skip-workflow-runs)」を参照してください。\n\nまた、コミットに対する \"すべて\" のチェックをスキップもしくはリクエストするには、以下のトレーラー行のいずれかをコミット メッセージの末尾に追加します。\\_\\_\n\n* コミットの\\_チェックをスキップ\\_には、コミットメッセージと変更の短く意味のある説明を入力してください。 コミットの説明の後、終了引用符の前に、2 つの空の行を追加してから `skip-checks: true` を追加します。\n\n  ```shell\n  $ git commit -m \"Update README\n  >\n  >\n  skip-checks: true\"\n  ```\n\n* コミットのチェックを\\_リクエスト\\_するには、コミットメッセージと変更の短く意味のある説明を入力してください。 コミットの説明の後、終了引用符の前に、2 つの空の行を追加してから `request-checks: true` を追加します。\n\n  ```shell\n  $ git commit -m \"Refactor usability tests\n  >\n  >\n  request-checks: true\"\n  ```\n\n既定では、Git は連続する改行を自動的に削除します。 コミット メッセージを入力したとおりのままにするには、コミットで`--cleanup=verbatim`オプションを使用します。 詳細については、Git ドキュメントにある「[`--cleanup=<mode>`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt)」を参照してください。\n\n## 状態と結論をチェックする\n\nチェックは、実行中に状態を移動し、完了すると結論を受け取ります。 一部の状態は手動で設定できず、 GitHub Actions用に予約されています。\n\n\\| 地位 | Description |\nGitHub Actions だけ。 |\n\\| --- | --- | --- |\n\\| `completed` | チェック実行が完了し、結論が得られました (下記参照)。 | いいえ |\n\\| `expected` | チェック実行は状態の報告待ちです。 | はい |\n\\| `failure` | チェック実行に失敗しました。 | いいえ |\n\\| `in_progress` | チェック実行が進行中です。 | いいえ |\n\\| `pending` | チェック実行はキューの先頭にありますが、[グループベースのコンカレンシー](/ja/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency)制限に達しています。 | はい |\n\\| `queued` | チェック実行がキューに登録されました。 | いいえ |\n\\| `requested` | チェックランは作成されましたが、キューに入れられていません。 | はい |\n\\| `startup_failure` | 起動時にチェック スイートが失敗しました。 この状態はチェック実行には適用されません。 | はい |\n\\| `waiting` |\n[配置保護規則](/ja/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)が満たされるまで、チェック実行は待機中です。 | はい |\n\nチェックの状態が `completed`は、結論があります。 成功した結論は、通常、チェックがマージをブロックしないことを意味します。 失敗、タイムアウト、またはアクションが必要な結論は、通常、プル要求をマージする前に詳細を確認する必要があります。\n\n| まとめ               | Description                                                                                                                                                                                        |\n| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `action_required` | チェック実行が完了すると、必要なアクションが提供されました。  詳細については、「[REST API を使用してチェックを操作する](/ja/enterprise-cloud@latest/rest/guides/using-the-rest-api-to-interact-with-checks#check-runs-and-requested-actions)」を参照してください。 |\n| `cancelled`       | チェック実行が完了する前に取り消されました。                                                                                                                                                                             |\n| `failure`         | チェック実行に失敗しました。                                                                                                                                                                                     |\n| `neutral`         | チェック実行はニュートラルな結果で完了しました。 これは、 GitHub Actionsの依存チェックの成功として扱われます。                                                                                                                                    |\n| `skipped`         | チェック実行はスキップされました。 これは、 GitHub Actionsの依存チェックの成功として扱われます。                                                                                                                                           |\n| `stale`           | チェックの実行に時間がかかりすぎるため、 GitHub によって古いマークが付けられました。                                                                                                                                                     |\n| `success`         | チェック実行は正常に完了しました。                                                                                                                                                                                  |\n| `timed_out`       | チェック実行はタイムアウトしました。                                                                                                                                                                                 |\n\n## チェックの保持\n\nGitHub では、チェック データが 400 日間保持されます。 400 日後、データはアーカイブされます。 アーカイブから 10 日後に、データは完全に削除されます。\n\n必須であり、アーカイブされているチェックと pull request をマージするには、チェックを再実行する必要があります。"}