使用可能な pull request 状態チェック

Azure DevOps サービス

状態チェックでは、テストが成功するか、セキュリティスキャンがクリアされるか、またはその他の条件が満たされるまで、マージをブロックすることで品質基準が適用されます。 Azure DevOpsサービスと外部ツールは、PR Status API を使用して状態チェックをポストします。

ブランチポリシーとして状態チェックを要求するには、[状態を確認する] セクションにポリシーを作成し、チェックのジャンルと名前をgenre/name形式で指定します。その後、pull request は、チェックが succeeded報告されるまでマージをブロックします。

状態の値とマージの動作

状態チェックで結果がプル要求にポストされると、次のいずれかの値が報告されます。

価値	必要なポリシーを使用した動作	オプションのポリシーを使用した動作
`succeeded`	✓ポリシーのブロックを解除します	参考情報
`failed`	✗ ブロックのマージ	参考情報
`error`	✗ ブロックのマージ	参考情報
`pending`	⏳ ブロックのマージ (結果の待機中)	参考情報
`notApplicable`	✓ ポリシー要件をバイパスする	参考情報
`notSet`	⏳ 保留中として扱われる	参考情報

注

必要なポリシーが 既定で [適用] に設定されている場合は、 notApplicable を投稿して、ポリシー構成を変更せずに特定の PR のポリシー要件を削除できます。これは、チェックが特定の変更に適用されない場合に便利です。

状態チェックポリシーを追加する一般的な手順については、「外部サービスのブランチポリシーを構成する」を参照してください。承認された ID 制限やポリシーの適用性設定など、高度なポリシーオプションについては、「プル要求の状態を使用して pull request ワークフローをカスタマイズおよび拡張する」を参照してください。

ファーストパーティのAzure DevOps状態チェック

Azure DevOps Services によってネイティブに投稿された唯一の状態チェックを次に示します。各チェックでは固定 のジャンル 値が使用されるため、サービスが最初の状態を投稿する前または後にブランチポリシーを構成できます。その他すべての状態チェックは、PR Status API を介して外部サービスから取得されます。

GitHub Advanced Security for Azure DevOps

これらの状態チェックでは、リポジトリでAzure DevOps GitHub Advanced Security を有効にする必要があります。このチェックでは、コードスキャン (CodeQL)、依存関係スキャン、シークレットスキャンで検出されたセキュリティの脆弱性が評価されます。

ジャンル	氏名	状態をチェック	Description
`AdvancedSecurity`	`AllHighAndCritical`	`AdvancedSecurity/AllHighAndCritical`	任意のスキャンの種類 (コード、依存関係、またはシークレット) からリポジトリに未解決の重大または高重大度の脆弱性が存在する場合にマージをブロックします。高度なセキュリティパイプラインタスクが有効になっているビルド検証ポリシーが必要です。
`AdvancedSecurity`	`NewHighAndCritical`	`AdvancedSecurity/NewHighAndCritical`	プル要求でスキャンの種類から新しい重大な脆弱性または重大度の高い脆弱性が発生した場合に、マージをブロックします。既存のリポジトリの脆弱性によってマージがブロックされることはありません。 PR ブランチをスキャンするには、高度なセキュリティパイプラインタスクを含むビルド検証ポリシーが必要です。

注

どちらの AdvancedSecurity 状態チェックでも、最新のスキャン結果が状態に反映されるように、 Wait for Processing: true で構成されたビルド検証ポリシーと Advanced Security スキャンタスクが必要です。依存関係スキャンまたはコードスキャン (CodeQL) の場合は、AdvancedSecurity-Publish タスクでWait for Processingを有効にします。コードスキャンの場合は、 AdvancedSecurity-CodeQL-Analyze タスクでも有効にします。どちらのチェックも 、[状態 ] ドロップダウンに表示され、高度なセキュリティスキャンを使用して最初にパイプラインが正常に実行された後に確認されます。

Tip

リポジトリに既存の未解決のアラートがある場合は、すべてのプル要求をすぐにブロックしないように、 AdvancedSecurity/NewHighAndCritical から始めます。アラートバックログが解決されたら、 AdvancedSecurity/AllHighAndCritical に移行します。

セットアップ手順については、「プル要求の状態チェックを設定する」を参照してください。

重要

状態チェックポリシーを構成する場合は、[ 詳細オプション] を 既定値のままにします。承認された ID を変更したり、繰り返し ID を要求したりすると、状態チェックが正しく投稿されなくなります。

コードカバレッジのAzure Pipelines

Azure Pipelines、パイプラインがプル要求のコードカバレッジの結果を発行するときに、コードカバレッジの状態チェックを自動的に投稿します。ジャンルはパイプライン名であるため、正確な genre/name 値は、パイプラインの名前付け方法によって異なります。

ジャンル	氏名	状態をチェック	Description
`{pipeline-name}`	`codecoverage`	`{pipeline-name}/codecoverage`	プル要求で変更された行の差分カバレッジ率を報告します。既定ではアドバイザリ。は、カバレッジの最小しきい値を持つ必要なブランチポリシーとして構成されていない限り、マージをブロックしません。

既定のパスしきい値は、差分カバレッジ% 70 です。しきい値やその他の設定を調整するには、リポジトリのルートに azurepipelines-coverage.yml ファイルを追加します。

coverage:
  status:
    comments: on
    diff:
      target: 80

80を目的の最小差分カバレッジ率に置き換えます。

セットアップ手順については、「コードカバレッジポリシーを使用してブランチ保護を適用する」を参照してください。

Tip

ジャンルは、Azure Pipelines内のパイプラインの表示名から派生します。個別に構成可能な値ではありません。たとえば、 CI - Main という名前のパイプラインでは、 CI - Main/codecoverage を Status として使用 して値を確認 します。状態チェックは、サービスが pull request に少なくとも 1 つの状態を投稿した後にのみ、ドロップダウンに表示されます。まだ実行されていない新しい統合の場合は、フィールドに直接 genre/name 値を入力します。

カスタムおよび外部の状態チェック

PR Status API を使用するサービスは、プル要求に状態チェックを投稿できます。 REST API を使用して状態チェックを投稿するには、呼び出し元 ID にリポジトリに対 する Pull requests アクセス許可を取得する 必要があります。

サービスが状態を投稿すると、その genre/name が [状態] に 表示され、ポリシーを追加するときにドロップダウンが表示されます。まだ投稿していない新しいサービスの場合は、 genre/name 値を直接入力します。

一般的な統合パターン

統合タイプ	Description	Examples
サーバーのビルドとテスト	PR ブランチに対してテストを実行した後、成功または失敗の結果をポストする外部 CI ツール。	Jenkins、GitLab CI、CircleCI、Travis CI
コード品質の分析	コードでバグ、脆弱性、コードの臭いをスキャンする静的分析ツール。	SonarQube、SonarCloud
セキュリティスキャナー	PR の変更をスキャンした後に結果を投稿するMicrosoft以外の脆弱性スキャナー。 SARIF 形式の結果もサポートしています。	Snyk、Checkmarx、WhiteSource (Mend)、Microsoft Security DevOps
コンプライアンスとポリシー	ライセンス、コード標準、規制要件、または展開の準備状況を確認するポリシー適用ツール。	カスタムコンプライアンスチェッカー、展開ゲート、ライセンススキャナー
GitHub Actions	リポジトリがGitHubに接続されている場合、GitHub Actionsワークフローからのチェックは Azure DevOps PR に表示されます。構成の詳細については、Azure DevOps GitHub統合を参照してください。	任意のGitHub Actionsワークフローで状態を投稿できます
承認とゲート	マージを許可する前に手動または自動の承認を必要とするサービス。	ServiceNow、REST API を使用したカスタム承認サービス

ポリシー構成オプション

状態チェックポリシーを追加する場合は、次の構成を行うことができます。

ポリシー要件: 必要に応じてポリシーを設定します (チェックに合格しない限り、マージをブロックします)、またはオプション (情報のみ)。
承認された ID: ポリシーを満たす状態値を投稿できるアカウントを制限します。任意のアカウントを許可するには、空白のままにします。
リセット条件: 新しいコミットがプッシュされたときに状態をリセットするかどうかを指定します。既定では、新しいコミットをプッシュすると、必要な状態チェックが保留中にリセットされ、最新のコードを評価するように強制されます。コミット間で状態を保持できるようにするには、 新しい変更がある場合は常にリセット状態を無効にします。
ポリシーの適用可能性: ポリシーがすぐに適用されるか (既定では適用されます)、最初の状態が投稿された後 (条件付き) のみを選択します。
- 既定で適用: ポリシーは、 succeeded 状態がポストされるまでマージをブロックします。 notApplicableを投稿して、特定の PR の要件をバイパスできます。
- 条件付き: ポリシーは、チェックが最初の状態を投稿した後にのみアクティブになります。
パスフィルター: 特定のパス内のファイルを変更する PR にポリシーを制限します (省略可能)。

カスタム状態チェックを実装するには、次を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-07