Una solicitud de pull request procedente de Coroid ya ha pasado por verificación antes de que la veas. Esta sección explica qué significa eso y cómo configurarlo.
Las capas
La verificación no es un único proceso. Existen cuatro capas que responden a preguntas distintas.
Tu suite de pruebas. Es la señal más fiable disponible, ya que ya incorpora lo que tu equipo considera importante. Coroid la ejecuta en un entorno limpio para cada tarea.
Puentes de calidad. Comprobaciones definidas por políticas: cobertura, linting, pruebas en navegador y las Comprobación de Globalización para proyectos multilingües. Los puentes bloqueantes detienen la tarea; los puentes consultivos registran un hallazgo y permiten que continúe. Consulta Políticas y puentes de calidad. El escaneo de Seguridad tiene su propio espacio: consulta Seguridad.
Revisión. Un agente revisor analiza el diff finalizado y genera hallazgos. Los hallazgos solucionables se devuelven al desarrollador como trabajo adicional; el resto se adjuntan al pull request.
Pruebas. Despliegues de vista previa, resultados de escaneo y variaciones de cobertura se adjuntan al propio pull request, de modo que la verificación llega junto con el código. Consulta Pruebas de revisión.
- Su conjunto de pruebas¿Rompe el cambio lo que ya funciona?
- Puertas de calidad¿Cumple con los estándares que establece tu política?
- Revisión¿Lo aceptaría un lector cuidadoso del diff?
- Evidencia¿Está la prueba adjunta al código?
- Su revisión¿Es este el cambio adecuado?
Todas las capas automatizadas se ejecutan antes de que exista el pull request, por lo que los fallos se devuelven como trabajo pendiente dentro de la ejecución.
Qué demuestra y qué no demuestra esto
La verificación confirma que el cambio cumple con lo estipulado, no rompe lo existente y satisface los estándares que tú definiste.
No demuestra que el cambio sea lo correcto para desarrollar. Eso es lo que sirven para las condiciones de aceptación en la especificación y para lo que sirve tu revisión.
Un cambio puede superar todas las capas y, aun así, ser incorrecto. Mantener esta distinción clara es lo que hace que el resto sea fiable: en cuanto la verificación se presenta como juicio, la gente deja de revisar.
El objetivo de ejecutarlo primero
Cada capa se ejecuta antes de que exista el pull request, de modo que los fallos se devuelven como trabajo adicional dentro del proceso en lugar de como un pull request que solo rechazarías.
Es más barato fallar en el entorno de trabajo que en tu pantalla. Tu revisión debe ser la primera revisión humana, no la primera visualización.
Por dónde empezar
Si estás configurándolo por primera vez:
- Asegúrate de que tu suite de pruebas funcione: consulta Configuración de compilación y pruebas. Nada más importa si esto no está bien.
- Establece una política predeterminada para la organización en tu nivel de estándar , no en el más estricto.
- Conecta los proveedores de pruebas que ya utilizas.
- Añade los puentes uno por uno, empezando por los consultivos.