extra-codeowners

Extra CODEOWNERS est une application GitHub auto-hébergée destinée aux équipes souhaitant automatiser l'approbation des pull requests de routine selon une politique CODEOWNERS. Elle publie un contrôle obligatoire qui accepte soit l'approbation d'un CODEOWNER humain, soit l'approbation d'une application GitHub explicitement inscrite. Un dépôt peut également choisir de considérer l'auteur d'une pull request éligible comme preuve de CODEOWNER humain pour ce contrôle. Les personnes et les équipes restent dans le fichier CODEOWNERS standard de GitHub, tandis qu'une politique distincte définit quelles applications peuvent couvrir quels propriétaires et quels chemins. Le projet existe car la règle « Require review from Code Owners » de GitHub reconnaît les personnes et les équipes, mais ne permet pas à une application GitHub de se substituer à elles. Si une application telle que Stampbot sait déjà qu'une pull request est de routine, GitHub attend tout de même un propriétaire du code humain. Extra CODEOWNERS remplace cette décision unique par un contrôle. Il évalue séparément chaque ensemble de propriétaires effectifs distincts. Chaque ensemble de propriétaires représenté par un chemin possédé doit être validé. Une seule pull request peut utiliser une approbation humaine pour un ensemble de propriétaires et une approbation d'application pour un autre. L'approbation d'une application n'est valable que si l'organisation a inscrit l'identité exacte de l'application, que le dépôt a adhéré, que la délégation couvre le chemin modifié et le CODEOWNER effectif, que les étiquettes requises sont présentes, que l'approbation s'applique à la tête actuelle de la pull request, et qu'aucun garde-fou de l'organisation ou intégré ne rend le chemin exclusivement humain. Une pull request mélangeant des chemins possédés délégués et non délégués nécessite toujours une couverture humaine pour chaque ensemble de propriétaires non délégués. Un chemin sans correspondance CODEOWNER effective ne crée aucune exigence de propriétaire du code, bien que le décompte d'approbations ordinaires et les autres règles s'appliquent toujours. GitHub conserve les règles de pull request ordinaires : nombre minimum d'approbations, gestion des examens obsolètes, commits signés et contrôles obligatoires non liés. Extra CODEOWNERS est destiné à remplacer uniquement « Require review from Code Owners ». Le contrat public de GitHub ne précise pas si l'examen d'une application tierce compte pour le minimum d'approbations ordinaires ; cette combinaison doit donc être testée dans un dépôt jetable avant toute utilisation. Un minimum non nul peut encore exiger un humain même lorsque le contrôle Extra CODEOWNERS réussit. L'application ne soumet pas d'examens, ne fusionne pas de pull requests, n'accorde pas d'accès à une autre application et ne modifie pas CODEOWNERS. Elle lit les preuves de GitHub et publie un seul Check Run. Le contrôle doit être lu comme le résultat d'une politique, et non comme un examen. Extra CODEOWNERS apparaît dans la zone des contrôles de GitHub, tandis que le décompte d'approbations ordinaires apparaît dans la zone d'examen. Les équipes doivent conserver une règle de minimum d'examens normale si nécessaire. Le contrôle est asynchrone. Lorsqu'une approbation est rejetée ou modifiée, un succès antérieur reste visible jusqu'à ce que GitHub livre l'événement et que l'application réinitialise et réévalue le contrôle. La réconciliation répare les livraisons manquées, mais n'est pas un mécanisme de révocation instantané. La règle native de propriétaire du code de GitHub doit être conservée pour une limite qui ne peut tolérer cette fenêtre de succès obsolète. La délégation est répartie sur deux portées de politique. CODEOWNERS décide quelles personnes ou équipes possèdent chaque chemin. La politique d'organisation décide quelles applications sont globalement approuvées, ainsi que les chemins qu'aucune application ne peut couvrir. La politique de dépôt décide quelle application inscrite peut couvrir quel propriétaire et quel chemin dans ce dépôt. La politique de dépôt peut restreindre la politique d'organisation, mais elle ne peut pas inscrire une application ni affaiblir un garde-fou d'organisation. Une politique de dépôt est un fichier TOML avec schema_version, enabled, et delegations contenant app, paths, for_owners, et required_labels. La valeur app est un alias provenant de la table apps de la politique d'organisation, qui lie l'alias à l'ID numérique immuable de l'application, son slug public et l'ID de l'utilisateur bot. Des exemples de fichiers de politique sont fournis sous examples/policy, et le guide de configuration couvre les deux portées, la correspondance des chemins, les étiquettes, les fichiers protégés intégrés et une issue de secours non sécurisée. Pour l'inspection locale, un checkout propre peut être exécuté avec Bash, Git et mise installés en clonant le dépôt et en exécutant mise trust, mise install, mise run bootstrap et mise run test. Le README conseille de lire mise.toml avant mise trust car cette commande enregistre une décision de confiance locale. Une exécution réussie se termine par la validation de la suite de tests. Elle n'enregistre pas d'application GitHub et ne prouve pas les contrats GitHub en direct. Pour publier un contrôle dans un dépôt de test, le tutoriel first-check est fourni. Les règles natives de propriétaire du code doivent rester activées partout où cela est important. Les images et graphiques Alpha sont destinés uniquement aux tests en mode shadow non obligatoires et doivent être épinglés par digest. Le projet est en pré-version. Les images et graphiques Alpha sont destinés uniquement aux tests en mode shadow non obligatoires et ne doivent pas imposer de fusions en production. Les images de prévisualisation héritées telles que main et ses tags sha et sha256 compagnons ne sont pas supportées et sont dangereuses pour le déploiement car elles précèdent le pipeline de version immuable. Le document d'état du projet sépare ce qui est utilisable aujourd'hui de ce qui bloque encore une version supportée. La documentation comprend l'état du projet, la comparaison avec CODEOWNERS natif, le modèle de menace, le tutoriel d'installation pour le développement, le guide de configuration, le guide de dépannage, les guides de déploiement et d'opérations, les bundles de notification des destinataires, les guides d'architecture et de maintenance, ainsi qu'un guide du contributeur. Le manuel complet est sur Read the Docs. Les politiques du projet couvrent le support, le signalement de vulnérabilités privées, les CVE OpenSSL et VEX, la gouvernance, le journal des modifications et la licence Apache 2.0. L'ensemble de badges indique la CI, les tests de propriété, la couverture, CodeQL, l'OpenSSF Scorecard, la documentation, Python 3.12 à 3.14 et la licence Apache-2.0.