Azure DevOps のビルド検証：期限切れのビルド、手動のキュー、プルリクのビルドが動かない理由
ブランチに Build validation（ビルド検証）のポリシーを付けると、そのブランチへのプルリクエストは、パイプラインでビルドが通らないと完了できなくなります。Azure Repos Git では、プルリクエストでパイプラインを動かす唯一の方法でもあります。YAML ファイルの pr: トリガーはそこでは何もしません。以下は Microsoft の ブランチ ポリシーの設定と管理、Azure Repos Git リポジトリのビルド、REST リファレンスの Requeue Policy Evaluation（英語）からまとめた、ポリシーの仕組み、ビルドが期限切れになる時、もう一度キューに入れる方法です。
設定の項目
- Build pipeline：動かすパイプライン。ポリシーを足す前に作っておく必要があります。XAML のビルド定義は使えず、検証のビルドの設定にはプロジェクトの管理者が要る、と Microsoft は書いています。
- Path filter（任意）：プルリクエストが当てはまるファイルを変えた時だけポリシーが効きます。
/かワイルドカードで始まらないパスは効きません。 - Trigger：Automatic (whenever the source branch is updated) は、プルリクエストを作った時と、プッシュのたびにビルドをキューに入れます。Manual は、ビルドをキューに入れるのをプルリクエストの人たちに任せます。どちらでも、ポリシーはビルドの結果を読みます。
- Policy requirement：Required のビルドは、成功しないとプルリクエストを完了できません。Optional のビルドは失敗を知らせますが、完了は止めません。
- Build expiration：ターゲット ブランチが更新された時、もう通ったビルドをどう扱うか（下）。
- Display name（任意）：プルリクエストでのポリシーの名前。無ければパイプラインの名前になります。
何をビルドするか
- ポリシーのパイプラインはマージコミットをビルドします。ソース ブランチをターゲット ブランチにマージした時のコードです。
- プッシュしたコミットに
[skip ci]と書いてあっても動きます。この印が止めるのは、ソース ブランチへのプッシュそのもので動くパイプラインだけです。 - プルリクエストのビルドで読む YAML ファイルは、そのマージの結果のものです。どちらか一方のブランチのものではありません。
プルリクのビルドが動かない理由
- YAML ファイルに書いている。Azure Repos Git のリポジトリでは、YAML の
pr:トリガーは使われません。Microsoft のトラブルシューティングは、代わりにブランチ ポリシーを使うように書いています（YAML スキーマによれば、pr:トリガーが使えるのは GitHub と Bitbucket Cloud だけです）。 - プルリクエストが下書き。下書きのプルリクエストは、ビルド検証のポリシーがあってもパイプラインを動かしません。下書きを公開した時に始まります。
- トリガーが Manual。誰かがビルドをキューに入れる必要があります。それまでポリシーは待ったままです。
- パスの絞り込みが変えたファイルに当てはまらない。あるいは、
/かワイルドカードで始まらないパスがあって、決して当てはまらない。 - パイプラインが設定で一時停止か無効になっている。その間はトリガーが効きません。
期限切れのビルド
- Immediately when <branch> is updated：ターゲット ブランチが更新されるたびに、ビルドのポリシーを失敗にして新しいビルドをキューに入れます。いちばん安全ですが、更新の多いブランチでは何度もビルドを待つことになります。
- After <n> hours if <branch> has been updated：ターゲット ブランチが更新された時、n 時間より前に通ったビルドを期限切れにします。
- Never：ターゲット ブランチが更新されても結果は変わりません。ビルドはいちばん少なくなりますが、しばらく更新していないプルリクエストを古い結果のまま完了できてしまいます。
- 期限切れの必須のビルドは、もう一度通るまで完了も自動完了も止めます。ひとりでにキューに入らなかった時（トリガーが Manual の時など）は、プルリクエスト・コマンドライン・API からもう一度キューに入れます。
コマンドラインと REST API でもう一度キューに入れる
az repos pr policy list --id <pr> --output tableで、プルリクエストのポリシーが Evaluation ID・状態・Expired の列・ビルドの ID と一緒に並びます。az repos pr policy queue --id <pr> --evaluation-id <evaluation-id>で、そのポリシーの評価をもう一度キューに入れます。Azure DevOps CLI は Azure DevOps Server では使えません。- REST API では、
PATCH …/_apis/policy/evaluations/{evaluationId}で状態をqueuedにすると評価がもう一度キューに入ります（スコープは Code (Read & write)）。応えるのは今のところビルドのポリシーだけで、もう一度キューに入れると新しいビルドが入り、まだ動いているビルドは取り消される、と Microsoft は書いています。
IntelliJ IDEA でのビルド検証
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。Azure DevOps Services と Azure DevOps Server のプルリクエストを、ブランチ ポリシーを平易な文にして IDE のツールウィンドウに並べます。ビルドのポリシーは表示名と、「満たしている」「満たしていない」「実行中」「待機中」「期限切れ」のどれかを出し、任意のポリシーには印を付けます。Pro では、失敗したビルド・期限切れのビルド・まだ始まっていないビルド（トリガーが Manual）に再実行のリンクが出て、同じ REST の呼び出しでキューに入れます。レビューの受信箱とブランチ ポリシーは無料、投票・コメント・完了・ビルドポリシーの再実行・プルリクの作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps は Microsoft Corporation の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：ほかのサービスの状態チェック · コメントの状態とコメントの解決のポリシー · 自動完了と任意のポリシー · 下書きのプルリクエスト · 必須のレビュー担当者とパスの絞り込み · ポリシーを回避する明示的なオーバーライド · English