Resumo

  • O Rapport agora recebe categorias e nomes de testes separados por espaços e expande todos os pares possíveis. Se o diretório de um par não existe, a função retorna antes da execução e o par não entra nos quatro contadores.
  • Um exemplo estático do repositório fixado produz quatro células solicitadas, das quais duas existem e duas não. O relatório descreve o que rodou, mas não reconcilia esse conjunto com a intenção do seletor.

Quatro células são solicitadas. Duas chegam ao resultado. Nenhuma linha explica a diferença.

Esse é o limite exposto pelo commit de 7 de setembro do Rapport, “Allow running multiple specific categories and tests”. A alteração se restringe a 2-test.sh, mas muda a unidade de evidência: duas listas viram uma matriz e a existência de diretório passa a decidir se cada pedido terá identidade observável.

No runner fixado no commit, o primeiro argumento contém categorias separadas por espaços; o segundo, nomes de testes no mesmo formato. Um laço percorre as categorias e outro aplica a mesma lista de testes a cada uma. Cada par vira tests/<categoria>/<teste> e é entregue a run_test.

A primeira decisão de run_test é verificar se o caminho é um diretório. Se não for, a função retorna zero imediatamente. Isso acontece antes de definir TESTID, antes de imprimir Test:, antes de invocar o run.sh do cenário e antes de somar Success, Failure, Skipped ou Unknown.

Logo, o caminho ausente não é classificado como sucesso. Também não é classificado como teste pulado. Ele fica fora da contabilidade.

O exemplo de quatro células

A árvore imutável da mesma revisão possui 21 diretórios de categoria e 337 caminhos com o formato tests/<categoria>/<teste>/run.sh. Nela existem sample/100-simple e sample/500-multi-step, mas não rfc9286/100-simple nem rfc9286/500-multi-step.

Com as categorias sample rfc9286 e os testes 100-simple 500-multi-step, os laços formam quatro pares. Os dois caminhos de sample podem chegar à execução. Os dois caminhos de rfc9286 retornam na verificação inicial. Somente os cenários executados podem alimentar os quatro resultados.

O exemplo é uma derivação estática do código e da árvore públicos, não uma execução feita para este artigo. O pacote de fontes não contém log de CI, relato de operador ou efeito em produção. Tampouco afirma que todas as categorias devam compartilhar os mesmos nomes de testes. Uma matriz esparsa pode ser deliberada e válida. O problema documental é que uma célula solicitada não recebe uma disposição explícita.

Essa distinção evita acusar os totais de estarem errados. Se os dois cenários existentes terminarem com sucesso, dois sucessos descrevem corretamente os arquivos run.sh executados. Mas não descrevem todo o denominador de quatro células visto por quem fez a seleção. Contar as duas ausências como falhas também seria incorreto. Pedido, expansão, presença, execução e resultado são registros diferentes.

A mudança ampliou a entrada, não o recibo

O runner anterior admitia formatos mais estreitos: todas as categorias, todos os testes de uma categoria, ou um par exato. O novo código troca esses ramos pelos laços aninhados. A mensagem do commit mostra separadamente múltiplas categorias e múltiplos testes, mas não documenta o uso combinado nem define o significado de uma célula sem diretório.

Não há base para atribuir ao autor uma intenção sobre esse cruzamento ou afirmar que ele conhecia os caminhos ausentes. O que o código permite observar é uma separação. Para a função shell, a ausência termina com status zero. Para o relatório, aquela combinação nunca adquiriu um ID de teste. Falta um inventário que ligue as duas coisas.

O README fixado descreve o Rapport como um testador de relying parties em estágio inicial, feito com scripts shell e voltado a uma implementação por execução. O runner reconhece famílias fort, Routinator, rpki-client e rpki-prover. Seus próprios avisos dizem que a suíte pode estar errada e que relying parties podem divergir. Para interpretar comparações sob essas cautelas, é preciso conhecer o conjunto que efetivamente entrou no teste.

A LACNIC inclui o Rapport em seu programa de código aberto, enquanto o repositório público oferece o código para inspeção. As fontes não o definem como certificação, requisito de compra ou validador de produção. A questão examinada aqui é a trilha de seleção de uma ferramenta pública.

Um recibo antes dos resultados

O Rapport poderia manter os quatro desfechos e acrescentar um recibo anterior à execução. Ele registraria os argumentos brutos, os tokens normalizados e cada par expandido. Para cada célula, indicaria se o diretório existe e se a decisão foi executar ou caminho ausente; depois, anexaria TESTID e o resultado quando houvesse execução.

O recibo não precisaria tratar ausência como erro. Ele permitiria separar uma matriz intencionalmente esparsa de erro de digitação, nome antigo ou cenário inaplicável. A automação poderia comparar quantos pares foram solicitados, encontrados, executados e reportados, sem inferir o denominador pelo silêncio.

Os contadores atuais respondem “o que o cenário devolveu?”. O registro ausente responde à pergunta anterior: “qual foi a disposição de cada célula pedida?”.