Saltar al contenido principal

​
Los pasos

  1. GitHub notifica a CodeWarden. Se abre un pull request, se reabre, se marca como listo para revisión o recibe un push. Los pull requests en borrador no se revisan.
  2. Verificaciones antes de leer nada. La revisión no se ejecuta si el repositorio está desactivado en la consola, si la instalación está suspendida, o si la organización no tiene un plan vigente o ya usó su cupo. No se publica nada en el pull request y, salvo en un repositorio desactivado, la revisión queda registrada en la consola con el motivo.
  3. Lectura a través de la API de GitHub. La lista de archivos modificados, el título y la descripción del pull request, y .codewarden.yml de la base branch. Si el archivo omite este pull request, la revisión se detiene aquí y queda registrada como skipped. Si no, CodeWarden lee el contenido actual de cada archivo modificado que vale la pena revisar. No se clona nada y no se ejecuta nada.
  4. Contexto adicional, cuando lo hay. Un ticket de Jira o un issue de Sentry enlazado en el pull request, y hasta tres archivos que el pull request no toca pero que usan código que él cambia, encontrados con la búsqueda de código de GitHub dentro del repositorio y leídos desde la base branch.
  5. Una llamada al modelo. Todo lo anterior va al modelo en una sola solicitud.
  6. Filtro. Se descartan los hallazgos por debajo del umbral de confianza, los que exceden el tope de comentarios, los que alguien ya decidió, los ya publicados en un push anterior o los que están fuera de las líneas que agregó el pull request.
  7. Publicar una revisión. Todos los comentarios en línea salen juntos en una sola revisión de GitHub, que nunca aprueba ni pide cambios.

​
Qué archivos se leen

Estos se omiten sin que lo pidas: Puedes agregar rutas con ignore y rescatar las incorporadas con unignore en .codewarden.yml. Un archivo sin diff, o con más de 1.500 líneas modificadas, no se puede rescatar. Los archivos omitidos se le nombran al modelo, para que sepa que forman parte del pull request y no los reporte como faltantes.

​
Cuánto de cada archivo

Los archivos pequeños (de menos de unos 20.000 caracteres) se envían completos, para que el modelo pueda ver una cláusula de guarda diez líneas arriba del cambio. Los archivos más grandes se envían como ventanas de 40 líneas alrededor de cada cambio. Cuando un pull request es muy grande, las ventanas se reducen, y solo después se dejan fuera, por nombre, los últimos archivos.

​
Revisión incremental

La primera revisión de un pull request lo lee todo. Después, cada push se revisa solo por lo que cambió. “El último commit revisado” significa la última revisión cuyos comentarios pudiste ver: una que se publicó o que no encontró nada. Una revisión que falló o se omitió no cuenta, así que el siguiente push se compara con código que alguien realmente revisó. La revisión incremental no se puede desactivar. Repetir un comentario que el autor ya respondió es como la gente aprende a dejar de leer un bot de revisión.

​
Qué se publica

  • Una primera revisión publica un resumen del cambio, incluso con cero comentarios.
  • Una revisión de seguimiento sin nada que decir no publica nada.
  • Los comentarios en línea van solo en líneas que el pull request agregó. GitHub rechaza una revisión completa si un solo comentario cae fuera del diff, así que cualquier comentario así se descarta antes de publicar.
  • El resumen termina con cuántos comentarios se publicaron y cuántos se filtraron. Cuando se leyó un ticket de Jira, agrega Checked against PROJ-123. y una lista de los requisitos del ticket, cada uno marcado según lo que muestra este cambio (detalles). Cuando se leyó un issue de Sentry, indica cuántos archivos del stack trace toca el cambio.

​
Qué decide qué comentarios se publican

​
Cuando una revisión falla

Si el modelo no responde a tiempo, la revisión se reintenta con menos de cada archivo, hasta tres intentos en total. Si el modelo responde dos veces con algo que no es el JSON que se le pidió, la revisión se detiene en lugar de adivinar. Una revisión que falla no publica nada, no usa ningún turno de IA y aparece en la consola con el estado failed. Un problema con Jira, Sentry o .codewarden.yml nunca hace fallar una revisión: la revisión continúa sin esa fuente.