extra-codeowners

Extra CODEOWNERS es una GitHub App auto-alojada para equipos que desean que la automatización apruebe pull requests rutinarios bajo una política de CODEOWNERS. Publica un check obligatorio que acepta ya sea la aprobación de un CODEOWNER humano o la aprobación de una GitHub App explícitamente enrolada. Un repositorio también puede optar por tratar al autor de un pull request elegible como evidencia de CODEOWNER humano para ese check. Las personas y los equipos permanecen en el archivo CODEOWNERS estándar de GitHub, mientras que una política separada define qué Apps pueden cubrir a qué propietarios y rutas. El proyecto existe porque la regla Require review from Code Owners de GitHub reconoce personas y equipos, pero no permite que una GitHub App actúe en su lugar. Si una App como Stampbot ya sabe que un pull request es rutinario, GitHub sigue esperando a un propietario del código humano. Extra CODEOWNERS reemplaza esa decisión única con un check. Evalúa cada conjunto de propietarios efectivos de forma separada. Cada conjunto de propietarios representado por una ruta propiedad debe pasar. Un mismo pull request puede usar una aprobación humana para un conjunto de propietarios y una aprobación de App para otro. La aprobación de una App califica solo cuando la organización enroló esa identidad de App exacta, el repositorio optó por participar, la delegación cubre la ruta modificada y el CODEOWNER efectivo, las etiquetas requeridas estén presentes, la aprobación se aplique al head actual del pull request y ninguna restricción de la organización o integrada haga que la ruta sea solo para humanos. Un pull request que mezcle rutas propiedad delegadas y no delegadas seguirá necesitando cobertura humana para cada conjunto de propietarios no delegados. Una ruta sin coincidencia de CODEOWNERS efectivos no crea un requisito de propietario de código, aunque las aprobaciones ordinarias y otras reglas siguen aplicando. GitHub mantiene las reglas ordinarias de pull request: recuento mínimo de aprobaciones, manejo de revisiones obsoletas, commits firmados y checks obligatorios no relacionados. Extra CODEOWNERS está destinado a reemplazar únicamente Require review from Code Owners. El contrato público de GitHub no especifica si la revisión de una App de terceros cuenta para el mínimo de aprobaciones ordinarias, por lo que esa combinación debe probarse en un repositorio desechable antes de confiar en ella. Un mínimo distinto de cero puede seguir requiriendo a un humano incluso cuando el check de Extra CODEOWNERS tenga éxito. La App no envía revisiones, no fusiona pull requests, no concede acceso a otra App ni edita CODEOWNERS. Lee la evidencia de GitHub y publica un Check Run. El check debe leerse como el resultado de una política, no como una revisión. Extra CODEOWNERS aparece en el área de checks de GitHub, mientras que el recuento de aprobaciones ordinarias aparece en el área de revisión. Los equipos deben mantener una regla de revisión mínima normal cuando sea necesario. El check es asíncrono. Cuando una aprobación es descartada o cambiada, un éxito previo permanece visible hasta que GitHub entrega el evento y la App restablece y reevalúa el check. La reconciliación repara las entregas perdidas, pero no es un mecanismo de revocación instantáneo. La regla nativa de propietarios de código de GitHub debe mantenerse para un límite que no pueda tolerar esa ventana de éxito obsoleto. La delegación se divide en dos alcances de política. CODEOWNERS decide qué personas o equipos son dueños de cada ruta. La política de organización decide qué Apps son confiables en general, además de las rutas que ninguna App puede cubrir. La política del repositorio decide qué App enrolada puede cubrir a qué propietario y ruta en ese repositorio. La política del repositorio puede restringir la política de la organización, pero no puede enrolar una App ni debilitar una restricción de la organización. Una política de repositorio es un archivo TOML con schema_version, enabled y delegations que contienen app, paths, for_owners y required_labels. El valor app es un alias de la tabla de apps de la política de la organización, que vincula el alias con el ID numérico inmutable de la App, su slug público y el ID del usuario bot. Se proporcionan archivos de política de ejemplo en examples/policy, y la guía de configuración cubre ambos alcances, coincidencia de rutas, etiquetas, archivos protegidos integrados y una salida de escape insegura. Para la inspección local, se puede ejecutar un checkout limpio con Bash, Git y mise instalados clonando el repositorio y ejecutando mise trust, mise install, mise run bootstrap y mise run test. El README aconseja leer mise.toml antes de mise trust porque ese comando registra una decisión de confianza local. Una ejecución exitosa termina con la superación de la suite de pruebas. No registra una GitHub App ni prueba los contratos en vivo de GitHub. Para publicar un check en un repositorio de prueba, se proporciona el tutorial first-check. Las reglas nativas de propietarios de código deben permanecer habilitadas en cualquier lugar donde sea importante. Las imágenes y charts Alpha son solo para pruebas en modo shadow no obligatorias y deben fijarse por digest. El proyecto está en fase de pre-lanzamiento. Las imágenes y charts Alpha son solo para pruebas en modo shadow no obligatorias y no deben imponer fusiones en producción. Las imágenes de vista previa heredadas, como main y sus etiquetas sha y sha256 complementarias, no cuentan con soporte y son inseguras para el despliegue porque son anteriores al pipeline de lanzamiento inmutable. El documento de estado del proyecto separa lo que es utilizable hoy de lo que aún bloquea un lanzamiento soportado. La documentación incluye el estado del proyecto, comparación con CODEOWNERS nativo, modelo de amenazas, tutorial de instalación para desarrollo, guía de configuración, guía de resolución de problemas, guías de despliegue y operaciones, paquetes de aviso al destinatario, guías de arquitectura y de mantenedor, y una guía para contribuyentes. El manual completo está en Read the Docs. Las políticas del proyecto cubren soporte, reporte de vulnerabilidades privadas, CVEs de OpenSSL y VEX, gobernanza, registro de cambios y Licencia Apache 2.0. El conjunto de insignias indica CI, pruebas de propiedad, cobertura, CodeQL, OpenSSF Scorecard, documentación, Python 3.12 a 3.14 y licencia Apache-2.0.