Résumé

  • Rapport accepte désormais des listes de catégories et de tests séparées par des espaces, puis construit leur produit cartésien. Une combinaison sans répertoire revient avant l’exécution et n’entre dans aucun des quatre totaux.
  • L’arbre figé du dépôt permet de dériver un exemple de quatre cellules demandées : deux chemins existent et deux sont absents. Les résultats décrivent correctement les scénarios exécutés, sans rendre compte de toute la demande.

L’utilisateur demande quatre cellules. Le compte rendu n’en représente que deux. Entre les deux, aucune ligne n’explique la soustraction.

C’est l’effet observable du commit Rapport du 7 septembre, « Allow running multiple specific categories and tests ». Le correctif ne touche que 2-test.sh, mais il modifie la frontière probatoire de l’outil : deux listes deviennent une matrice, puis l’existence d’un répertoire décide si une cellule aura une identité publique.

Dans le script figé, le premier argument contient des catégories séparées par des espaces et le second des noms de tests sous la même forme. La boucle externe parcourt les catégories; la boucle interne applique la même liste de tests à chacune d’elles. Chaque couple produit le chemin tests/<catégorie>/<test>, transmis à run_test.

run_test vérifie d’abord que ce chemin est un répertoire. Sinon, la fonction renvoie immédiatement le code zéro. Ce retour précède l’affectation de TESTID, l’affichage de la ligne Test:, le lancement de run.sh et toute incrémentation de Success, Failure, Skipped ou Unknown.

Le chemin absent n’est donc ni un succès ni un test ignoré. Il reste en dehors du compte rendu.

Une matrice dont le dénominateur change en silence

L’arbre immuable du même commit comporte 21 répertoires de catégories et 337 chemins de type tests/<catégorie>/<test>/run.sh. Il contient sample/100-simple et sample/500-multi-step, mais pas rfc9286/100-simple ni rfc9286/500-multi-step.

Avec les catégories sample rfc9286 et les tests 100-simple 500-multi-step, le code construit quatre couples. Les deux chemins sample peuvent atteindre leur scénario. Les deux chemins rfc9286 reviennent au contrôle d’existence. Seuls les scénarios lancés alimentent les compteurs.

Il s’agit d’une lecture statique du code et de l’arbre publics, pas d’une exécution locale. Les sources ne contiennent ni journal CI, ni compte rendu d’opérateur, ni impact en production. Elles ne disent pas non plus que toutes les catégories devraient partager les mêmes noms de tests. Une cellule absente peut être parfaitement normale. L’information manquante est sa disposition explicite.

Cette réserve protège aussi l’exactitude des chiffres. Si les deux scénarios présents réussissent, deux succès décrivent fidèlement ce qui s’est exécuté. Ils ne suffisent pas à décrire les quatre cellules que la commande avait demandé de développer. Transformer les deux absences en échecs serait tout aussi trompeur. Le bon modèle sépare l’intention de sélection, la présence sur disque, l’exécution et l’issue.

De trois formes de sélection à une expansion imbriquée

Le script parent proposait des chemins plus étroits : toutes les catégories, tous les tests d’une catégorie, ou un couple exact. Le commit actuel remplace ces branches par les boucles imbriquées. Son message illustre séparément plusieurs catégories et plusieurs tests, sans définir la combinaison des deux listes ni le statut d’une cellule inexistante.

Ce vide documentaire ne permet pas de prêter une intention à l’auteur. Il montre seulement que « terminer » a deux sens. La fonction shell termine avec succès pour un chemin absent; le rapport de tests termine sur l’ensemble réduit des scénarios exécutables. Aucun inventaire ne rapproche ces deux ensembles.

Le README figé décrit Rapport comme un testeur de relying parties encore au début de son développement, écrit sous forme de scripts shell, avec une implémentation ciblée par exécution. Il cite les familles fort, Routinator, rpki-client et rpki-prover. Le script avertit aussi que la suite peut se tromper et que des relying parties peuvent diverger. Dans un outil comparatif, ces précautions rendent le périmètre exécuté essentiel.

LACNIC inscrit Rapport dans son travail open source, et le dépôt officiel permet cet examen public. Rien dans ces pages n’en fait une certification, une règle d’achat ou un validateur de production. L’enjeu ici est plus précis : la traçabilité d’un choix de tests.

Émettre le reçu avant de lancer les scénarios

Rapport pourrait conserver ses quatre issues tout en ajoutant un reçu de sélection. Celui-ci enregistrerait les arguments bruts, les jetons normalisés, tous les couples développés, l’existence de chaque répertoire et la décision exécuter ou chemin absent. Après le lancement, le même enregistrement recevrait TESTID et l’issue du scénario.

Un tel reçu ne qualifierait pas l’absence d’erreur. Il permettrait de distinguer une matrice volontairement creuse d’une faute de frappe, d’un nom devenu obsolète ou d’un scénario non pertinent pour une catégorie. Un système d’automatisation pourrait comparer les nombres de cellules demandées, présentes, exécutées et rapportées au lieu de transformer le silence en hypothèse.

Les quatre compteurs répondent à la question « qu’a renvoyé le scénario ? ». Le reçu répondrait à la question antérieure : « qu’est devenue chaque cellule demandée ? »