GitHub App

Cada pull request revisado. Cada corrección, un PR.

Codna revisa cada pull request y aprueba un diff limpio. Pide una corrección desde una etiqueta de issue, un comentario o un check en rojo, y Codna abre el pull request para que lo fusiones.

Instalar la appLeer docs

Cómo funciona

Del pull request al veredicto. Del issue al PR de corrección.

01

Instalar en repos

Instala en tu cuenta u organización y elige los repositorios. Vincula la instalación a tu cuenta de Codna para correcciones gestionadas, o añade tu propia clave.

02

Revisar cada pull request

Codna publica hallazgos con severidad, categoría y confianza, hasta diez con confianza 0,75 o superior, con cambios sugeridos en línea. Un diff limpio recibe una aprobación. Las re-revisiones cubren solo los commits nuevos.

03

Abrir PRs de corrección

Dispara una corrección desde la etiqueta codna-fix, una respuesta @codna fix en un hallazgo o una check suite en rojo. Codna hace triage de una suite en rojo primero, así un fallo de infraestructura no cuesta nada.

04

Mantener el control

Codna nunca hace merge. Las reglas de rama, los checks requeridos y tu revisión siguen al mando. Los administradores pueden desactivar las correcciones automáticas para la organización.

Comandos por comentario

Comenta para ejecutar Codna.

Dos verbos, al inicio de una línea. Las correcciones requieren acceso de escritura al repositorio, y un fork recibe el cambio sugerido en su lugar.

@codna review
@codna fix        # reply on a Codna finding

labels: codna-fix · codna-secure
Evidencia del PR

Cada PR se explica solo.

Cada PR de corrección indica el issue, la causa raíz, los símbolos tocados y una puntuación de confianza, y pide revisión antes del merge. Los commits vienen de codna-ai[bot].

Causa raízuna frase
Confianza0 a 100 %
Check runcodna review · codna fix · codna secure

Preguntas frecuentes

Hallazgos en línea con severidad (alta, media, baja), una categoría (corrección, seguridad, rendimiento) y una puntuación de confianza, con un cambio sugerido cuando aplica. Un diff limpio en media y alta recibe una aprobación que cuenta para las reglas de rama; en otro caso Codna comenta. Nunca solicita cambios. Desactiva las aprobaciones con review.approve: false.

El check codna review aparece como en cola en el momento en que haces push. Un commit superado termina neutral y se revisa el nuevo head. Cuando un check requerido falla, la revisión lo dice junto al veredicto: el veredicto es sobre el diff, no una autorización de merge. Las merge queues heredan el veredicto del pull request.

Añade la etiqueta codna-fix. Codna mapea el repositorio por cero tokens, corrige desde un paquete de evidencia y abre un pull request que indica issue, causa raíz, símbolos y confianza. Si el parche no pasa la puerta de riesgo, no se sube nada y Codna explica por qué.

Una cuenta vinculada incluye un saldo de modelo gestionado de unos 5 $ al mes. Añade tu propia clave en la página de cuenta para uso sin límite y facturado por ti. En 87 casos medidos, una corrección verificada promedió unos 0,02 $ de gasto en modelo.

Las revisiones se completan en 4 a 20 minutos según el tamaño del pull request; una revisión agotada lo dice y pide @codna review o un PR más pequeño. Una corrección por fallo de CI por head de pull request al día. Los jobs terminan a los 30 minutos. Las ejecuciones de tests alojadas usan pytest; otros runners terminan neutral con una pista para configurar fix.test_command. @codna fix requiere acceso de escritura y no corre en pull requests de forks.

Tokens de corta duración y acotados al repositorio por job. Review: contents lectura, pull requests escritura, checks escritura, statuses lectura. Fix: contents, pull requests, checks, issues y workflows escritura. Secure: contents y security events lectura, checks e issues escritura. El agente de revisión no tiene token de escritura.