Resumen

  • Rapport acepta listas de categorías y pruebas separadas por espacios y expande todos sus pares. Cuando no existe el directorio de un par, la función regresa antes de ejecutar y ese par no figura en ningún total.
  • Un ejemplo estático del árbol fijado produce cuatro celdas solicitadas, dos rutas existentes y dos ausentes. El informe puede contar bien lo ejecutado y, al mismo tiempo, no revelar todo lo seleccionado.

La orden describe cuatro celdas. El resultado puede hablar solo de dos. No hay una tercera cifra que explique la diferencia.

Esa asimetría nace del commit de Rapport del 7 de septiembre, cuyo mensaje es “Allow running multiple specific categories and tests”. El cambio modifica únicamente 2-test.sh, pero amplía la semántica de la entrada: dos listas dejan de ser opciones aisladas y pasan a generar una matriz.

El runner fijado en ese commit interpreta el primer argumento como categorías separadas por espacios y el segundo como nombres de pruebas. Recorre cada categoría y aplica a todas la misma lista de pruebas. Para cada combinación construye tests/<categoría>/<prueba> y llama a run_test.

Antes de asignar TESTID, imprimir Test: o iniciar el run.sh del escenario, run_test comprueba si la ruta es un directorio. Si no lo es, retorna cero. Los contadores Success, Failure, Skipped y Unknown solo se actualizan después de que un escenario existente devuelve su código.

Por tanto, la ausencia no se registra como éxito. Tampoco como omisión. Simplemente no entra en el universo de resultados.

Cuatro selecciones, dos ejecuciones representadas

El árbol inmutable de la revisión contiene 21 directorios de categoría y 337 rutas con el patrón tests/<categoría>/<prueba>/run.sh. En ese árbol existen sample/100-simple y sample/500-multi-step; no existen rfc9286/100-simple ni rfc9286/500-multi-step.

Si se combinan las categorías sample rfc9286 con las pruebas 100-simple 500-multi-step, los bucles construyen cuatro pares. Dos rutas de sample pueden ejecutar sus escenarios. Dos rutas de rfc9286 terminan en la comprobación inicial. Los cuatro contadores solo pueden reflejar los dos escenarios alcanzados.

Este ejemplo no es una ejecución hecha para el artículo. Es una derivación estática del código y del árbol públicos. No hay registro de CI, reporte de un operador ni evidencia de impacto en producción. Tampoco hay base para afirmar que cada categoría debe ofrecer el mismo vocabulario de pruebas. Una celda ausente puede ser correcta. Lo que falta es una disposición visible que diga que fue solicitada, expandida y descartada por ausencia de ruta.

Esa precisión evita una acusación equivocada contra los totales. Si ambos escenarios existentes terminan con éxito, “dos éxitos” es un resultado válido para los archivos run.sh ejecutados. No es un balance completo de las cuatro celdas solicitadas. Convertir automáticamente las dos ausencias en fallos también sería incorrecto. La solución consiste en conservar dos capas de evidencia.

La expansión cambió el contrato práctico

El runner anterior cubría todos los grupos, todas las pruebas de una categoría o un par exacto. El nuevo código sustituye esas ramas por bucles anidados. El mensaje del commit muestra por separado múltiples categorías y múltiples pruebas, pero no documenta la invocación combinada ni define la semántica de una celda ausente.

No se puede inferir que el autor pretendiera ese caso o conociera cada hueco. Sí puede observarse una separación: para la función shell, una ruta ausente termina con estado cero; para el informe, nunca hubo una prueba con identidad. Falta un artefacto que concilie ambas perspectivas.

El README de la revisión presenta Rapport como un tester de relying parties en desarrollo temprano, implementado con scripts shell y dirigido a una implementación por ejecución. El runner contempla familias fort, Routinator, rpki-client y rpki-prover, y advierte que la propia suite puede equivocarse y que otras relying parties pueden discrepar. Para interpretar una comparación así, conocer el conjunto efectivamente ejecutado es indispensable.

LACNIC sitúa Rapport entre sus proyectos de código abierto, y el repositorio público permite revisar el mecanismo. Ninguna fuente lo presenta como certificación, requisito de compra o validador de producción. El asunto es la calidad del rastro de selección, no un incidente operativo.

Un recibo de selección previo

Antes de probar la existencia de las rutas, Rapport podría registrar los argumentos originales, los tokens normalizados y la lista completa de pares expandidos. Cada par recibiría campos sencillos: si existe, si se ejecutará, su TESTID cuando corresponda y el resultado final después del escenario. Una ausencia tendría una disposición explícita, no un veredicto.

Ese recibo permitiría separar una matriz intencionalmente dispersa de un error tipográfico, un nombre obsoleto o una prueba que no aplica a cierta categoría. También permitiría que CI compare cuatro cantidades distintas: solicitado, presente, ejecutado y reportado.

Rapport ya conserva cuatro resultados útiles para escenarios reales. La mejora no exige cambiarlos. Exige documentar la etapa anterior, donde una intención del operador se convierte en el denominador del informe.