Azure DevOps のプルリクの状態チェック：状態のポリシーが待ち続ける理由、genre/name、notApplicable
CI のサーバー、SonarQube や SonarCloud、セキュリティのスキャナーなど、Azure Repos の外のサービスは、プルリクエストに状態（status）を投稿して結果を知らせます。ブランチ ポリシーの Status checks を付けると、プルリクエストはその状態を待つようになります。以下は Microsoft の プル要求ワークフローの拡張性、Available pull request status checks（英語）、外部サービスのブランチ ポリシーを構成する、REST リファレンスの Pull Request Statuses（英語）からまとめた、状態とポリシーの仕組み、状態のポリシーが待ち続ける理由です。
状態とは
- State（状態）：
succeeded・failed・error・pending・notSet・notApplicableのどれか。Web の画面では、succeeded は緑のチェック、failed は赤い ×、pending は時計、error は赤い ! で出ます。 - Description（説明）：アイコンの横の文。「Build in progress」など。
- Context（文脈）：genre（たいていはサービスの種類。
continuous-integrationなど）と name の組で、genre/nameと書きます。Web の画面ではツールチップに出ます。 - Target URL：あれば、説明がサービスの結果のページへのリンクになります。
- サービスは、同じ文脈で新しい状態を投稿して結果を更新します。表示されるのは文脈ごとに最新の1件だけなので、pending の後に succeeded か failed、がよくある流れです。
反復（iteration）への状態
- 元ブランチへ push するたびに、プルリクエストに新しい反復ができます。状態は特定の反復に投稿でき、そうすると評価したコードだけに当てはまります。コードによらないチェック（作成者がだれか、など）はプルリクエスト全体に投稿します。
- コードを確かめる状態なら、Microsoft はポリシーの Reset conditions を Reset status whenever there are new changes にするよう勧めています。最新の反復に succeeded が付くまで、プルリクエストを完了できなくなります。
- 変更したファイルが 100,000 を超えるプルリクエストには反復ができず、ない反復へ状態を投稿するとエラーになります。
Status checks のポリシー
- ブランチの Branch policies の Status checks で + を押し、Status to check で前に投稿された状態を選びます。まだ投稿していないサービスなら
genre/nameを直接入力します。 - Policy requirement：Required（必須）なら、その文脈で succeeded の状態がないと完了できません。Optional（任意）は知らせるだけです。
- Authorized identity：このアカウントが投稿した状態だけを数えます。空ならどのアカウントでも数えます。
- Reset conditions：新しい push で投稿済みの状態を古いものとみなすか（上）。
- Policy applicability：Apply by default はプルリクエストを作った時からかかるので、succeeded が届くまで満たしません。Conditional は最初の状態が投稿されてからかかります。
- Path filter（任意）と Default display name（任意）は、ほかのブランチ ポリシーと同じです。
- 状態のポリシーを設定するには、Edit policies の権限か、Project Administrators の一員であることが要ります。
状態のポリシーが待ち続ける理由
- サービスがまだ投稿していない。それまで新しいポリシーは「not set」と出ます。pending や notSet でも必須のポリシーは待ち続け、failed と error は止めます。
- 文脈が合っていない。ポリシーは
genre/nameがそのとおりの状態を待ちます。まだ投稿していないサービスのために手で入力した値が、いちばん間違えやすい所です。 - 別のアカウントが投稿した。Authorized identity を決めていると、ほかのアカウントの状態は数えません。
- 新しい push で戻った。Reset status whenever there are new changes なら、前の succeeded は、サービスが最新のコードに投稿するまで数えません。
- この変更にはチェックが要らない。Apply by default なら、サービス（やスクリプト）が
notApplicableを投稿すると、ポリシーを変えずに、そのプルリクエストだけ要件が外れます。
Azure DevOps 自身が出すチェック
- GitHub Advanced Security for Azure DevOps は
AdvancedSecurity/AllHighAndCritical（リポジトリに未解決の重大・高の警告が1つでもある）とAdvancedSecurity/NewHighAndCritical（そのプルリクエストが増やした分だけ）を出します。どちらも Advanced Security のタスクを入れたビルド検証のポリシーが要り、Microsoft はポリシーの詳細オプションを既定のままにするよう書いています。 - Azure Pipelines のコード カバレッジは
{パイプライン名}/codecoverageに、プルリクエストが変えた行のカバレッジを出します（既定は 70%、azurepipelines-coverage.ymlで変えられます）。 - ほかの状態はすべて、外のサービスが REST API で投稿したものです。Jenkins などの CI、SonarQube や SonarCloud などのコード品質の道具、セキュリティのスキャナー、承認のサービスなど。
REST API での投稿と読み取り
POST …/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=7.1にstate・description・context（name・genre）・targetUrlを送ると状態を投稿できます。iterationIdを付けると反復に結び付きます。トークンには Code (Read & write) か Code (Status) が、アカウントには Contribute to pull requests の権限が要ります。- 同じ住所への
GETで、投稿されたすべての状態を Code (Read) で読めます。 - この資源は REST 7.0（Azure DevOps Server 2022）で正式になりました。それより前のサーバーでは 4.1（TFS 2018 Update 2）までさかのぼってプレビューとしてあり、
api-version=6.0-preview.1のように指定します。
IntelliJ IDEA での状態チェック
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。Azure DevOps Services と Azure DevOps Server のプルリクエストを、ブランチ ポリシーを平易な文にして IDE のツールウィンドウに並べます。Status checks のポリシーは genre/name と、「満たしている」「満たしていない」「待機中」のどれかを出します。1.0.61 からは、ほかのサービスが投稿した状態も概要に出します。文脈ごとに最新の1件を、問題のあるものから先に並べ、説明はサービスのページへのリンクにします（Web の画面の状態の欄と同じ）。レビューの受信箱・ブランチ ポリシー・状態は無料、投票・コメント・完了・プルリクの作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps は Microsoft Corporation の商標、IntelliJ IDEA は JetBrains s.r.o. の商標、SonarQube と SonarCloud は SonarSource SA の商標です。このページは Microsoft・JetBrains・SonarSource のいずれとも提携しておらず、承認も受けていません。
ほかに：ビルド検証と期限切れのビルド · 自動完了と任意のポリシー · 必須のレビュー担当者とパスの絞り込み · ポリシーを回避する明示的なオーバーライド · English