extra-codeowners

Extra CODEOWNERSは、CODEOWNERSポリシーに基づいた定型的なプルリクエストの承認を自動化したいチーム向けのセルフホスト型GitHub Appです。このAppは、人間のCODEOWNERによる承認、または明示的に登録されたGitHub Appによる承認のいずれかを受け入れる必須チェックを公開します。また、リポジトリの設定により、適格なプルリクエスト作成者をそのチェックにおける人間のCODEOWNERとしての証拠として扱うことも可能です。ユーザーやチームはGitHub標準のCODEOWNERSファイルに留まり、別のポリシーでどのAppがどのオーナーやパスをカバーできるかを定義します。 このプロジェクトが開発された理由は、GitHubの「Require review from Code Owners」ルールが人間とチームは認識するものの、GitHub Appをその代わりとして認めていないためです。StampbotのようなAppがプルリクエストを定型的であると判断しても、GitHubは依然として人間のコードオーナーによる承認を待ちます。Extra CODEOWNERSはこの単一の判断をチェックに置き換えます。各有効なオーナーセットを個別に評価し、所有パスで表されるすべてのオーナーセットがパスする必要があります。1つのプルリクエストで、あるオーナーセットには人間の承認を、別のオーナーセットにはAppの承認を使用することが可能です。Appの承認が有効となるのは、組織がそのApp IDを登録し、リポジトリがオプトインし、委任が変更されたパスと有効なCODEOWNERをカバーしており、必要なラベルが存在し、承認が現在のプルリクエストのヘッドに適用され、かつ組織または組み込みのガードレールによってそのパスが人間限定になっていない場合に限られます。委任されたパスと委任されていないパスが混在するプルリクエストでは、委任されていないオーナーセットごとに引き続き人間のカバーが必要です。有効なCODEOWNERSの一致がないパスについては、コードオーナーの要件は生成されませんが、通常の承認カウントやその他のルールは引き続き適用されます。 GitHubは、最小承認数、古いレビューの処理、署名付きコミット、および無関係な必須チェックなどの通常のプルリクエストルールを維持します。Extra CODEOWNERSは、「Require review from Code Owners」のみを置き換えることを目的としています。サードパーティAppのレビューが通常の最小承認数にカウントされるかどうかはGitHubの公開仕様に明記されていないため、依存させる前に使い捨てのリポジトリでテストすることを推奨します。最小承認数がゼロでない場合、Extra CODEOWNERSチェックが成功しても、依然として人間による承認が必要な場合があります。このAppはレビューの送信、プルリクエストのマージ、他のAppへのアクセス権限付与、またはCODEOWNERSの編集は行いません。GitHubの証拠を読み取り、1つのCheck Runを公開します。 このチェックはレビューではなく、ポリシーの結果として読み取るべきです。Extra CODEOWNERSはGitHubのチェック領域に表示され、通常の承認数はレビュー領域に表示されます。必要に応じて、チームは通常の最小レビュールールを維持してください。このチェックは非同期です。承認が却下または変更された場合、GitHubがイベントを配信し、Appがチェックをリセットして再評価するまで、以前の成功状態が表示され続けます。リコンシリエーション（整合性確認）によって配信漏れは修復されますが、即時の取り消しメカニズムではありません。そのような古い成功状態のウィンドウを許容できない境界条件では、GitHubネイティブのコードオーナールールを維持してください。 委任は2つのポリシー範囲に分かれています。CODEOWNERSはどの人間またはチームが各パスを所有するかを決定します。組織ポリシーは、どのAppを全面的に信頼するか、およびAppがカバーしてはいけないパスを決定します。リポジトリポリシーは、そのリポジトリにおいて登録済みのどのAppがどのオーナーとパスをカバーできるかを決定します。リポジトリポリシーは組織ポリシーを制限することはできますが、Appを登録したり組織のガードレールを弱めたりすることはできません。リポジトリポリシーはTOML形式で、schema_version、enabled、およびapp、paths、for_owners、required_labelsを含むdelegationsで構成されます。appの値は組織ポリシーのappsテーブルにあるエイリアスであり、このエイリアスがAppの不変の数値ID、パブリックスラグ、およびボットユーザーIDに紐付けられます。ポリシーファイルの例はexamples/policyに提供されており、設定ガイドでは両方の範囲、パスマッチング、ラベル、組み込みの保護ファイル、および非セキュアなエスケープハッチについて説明しています。 ローカルでの検証には、Bash、Git、miseがインストールされた環境で、リポジトリをクローンし、mise trust、mise install、mise run bootstrap、mise run testを実行することでクリーンチェックアウトが可能です。READMEでは、mise trustコマンドがローカルの信頼決定を記録するため、その前にmise.tomlを読むことを推奨しています。正常に実行されればテストスイートがパスします。ただし、これによりGitHub Appが登録されたり、ライブのGitHubコントラクトが証明されたりすることはありません。テストリポジトリでチェックを公開するには、first-checkチュートリアルが提供されています。重要な場所ではネイティブのコードオーナールールを有効にしたままにしてください。アルファ版のイメージとチャートはシャドウモードのテスト専用であり、ダイジェストで固定して使用してください。 本プロジェクトはプレリリース段階です。アルファ版のイメージとチャートは、必須ではないシャドウモードのテスト専用であり、本番環境のマージを強制するために使用しないでください。mainおよびそのsha、sha256コンパニオンタグなどのレガシープレビューイメージは、不変のリリースパイプラインより前のものであるため、サポートされておらずデプロイには安全ではありません。プロジェクトステータス文書では、現在利用可能な機能と、サポートされるリリースを妨げている機能が区別されています。ドキュメントには、プロジェクトステータス、ネイティブCODEOWNERSとの比較、脅威モデル、開発用インストールチュートリアル、設定ガイド、トラブルシューティングガイド、デプロイおよび運用ガイド、受信通知バンドル、アーキテクチャおよびメンテナーガイド、およびコントリビューターガイドが含まれています。完全なマニュアルはRead the Docsにあります。プロジェクトポリシーは、サポート、プライベートな脆弱性報告、OpenSSL CVEおよびVEX、ガバナンス、変更履歴、およびApache License 2.0をカバーしています。バッジセットは、CI、プロパティテスト、カバレッジ、CodeQL、OpenSSF Scorecard、ドキュメント、Python 3.12から3.14、およびApache-2.0ライセンスを示しています。