要約

  • Rapportの現行ランナーは、空白で区切ったカテゴリー列とテスト列から全組み合わせを作る。対応ディレクトリがない組み合わせは実行前に戻り、4種類の集計のどれにも現れない。
  • 固定されたリポジトリツリーから静的に導ける例では、要求された4セルのうち2経路が存在し、2経路が存在しない。集計は実行分について正しくても、要求分母を示さない。

4つを要求し、2つを実行する。ところが、結果表には残り2つを説明する欄がない。

この境界は、9月7日のRapportの公式コミット「Allow running multiple specific categories and tests」に表れている。変更ファイルは 2-test.sh だけだが、入力の扱いは広がった。カテゴリーの列とテスト名の列から直積を作り、各セルのディレクトリがある場合だけ結果の世界に入れる。

当該コミットに固定したランナーは、第1引数を空白区切りのカテゴリー、第2引数を空白区切りのテスト名として読む。外側のループでカテゴリーを選び、各カテゴリーに同じテスト名列を適用する。こうして tests/<category>/<test> を組み立て、run_test に渡す。

run_test は最初に、そのパスがディレクトリかを確認する。違えば直ちにステータス0で戻る。この時点では TESTID もカテゴリー名も設定されず、Test: の行も表示されず、シナリオの run.sh も呼ばれない。Success、Failure、Skipped、Unknownのカウンターが増えるのは、存在するシナリオが終了した後だけである。

したがって、存在しないセルは成功ではない。スキップでもない。最終結果の集合に含まれない。

4セルの要求と2件の記録

同じリビジョンの固定ツリーには、21のカテゴリーディレクトリと、tests/<category>/<test>/run.sh に一致する337のパスがある。そこには sample/100-simple と sample/500-multi-step がある一方、rfc9286/100-simple と rfc9286/500-multi-step はない。

カテゴリーとして sample rfc9286、テストとして 100-simple 500-multi-step を与えれば、コードが作るセルは4つである。2つの sample パスは実行に進める。2つの rfc9286 パスはディレクトリ確認で戻る。4種類の最終カウンターが扱えるのは前者だけだ。

これは公開ソースとツリーの静的読解であり、この記事のために行ったRapport実行の記録ではない。CIログ、運用者の報告、実運用への影響を示す資料もない。また、全カテゴリーが同じテスト名を実装すべきだとも資料は述べていない。疎な行列は正当な設計であり得る。問題は空白そのものではなく、要求されたセルの処置が表示されないことにある。

この限定はカウンターの意味も守る。存在する2シナリオがともに成功すれば、「成功2」は実行された run.sh の集計として正しい。ただし、選択された4セルの説明としては不足する。存在しない2セルを失敗に読み替えるのも誤りだ。要求、展開、存在確認、実行、結果という別々の段階を残す必要がある。

選択機能を広げたときの証拠

親リビジョンのランナーは、全カテゴリー、1カテゴリー内の全テスト、または1つの厳密な組み合わせという、より限定された分岐を持っていた。現行コミットはそれを入れ子ループに置き換えた。コミットメッセージは複数カテゴリーと複数テストを別々に例示するが、両方を同時に指定した場合や、存在しないセルの意味までは定義していない。

そこから作者の意図や認識を推測することはできない。確認できるのは、終了の意味が二つに分かれたことだけだ。シェル関数はパス不在をゼロで終了する。テスト報告から見れば、そのセルにはテストIDが一度も与えられない。両者を照合する資料がない。

固定版のREADMEは、Rapportを開発初期のRPKI relying partyテスターと位置付け、シェルスクリプトで構成し、1回の実行で1つのrelying party実装を対象にすると説明する。ランナーはfort系、Routinator、rpki-client、rpki-proverを選べる。さらに、テストスイート側が誤る可能性や、relying party間で見解が異なる可能性も注意している。この慎重さがあるからこそ、何を比較集合に入れたかが重要になる。

LACNICはRapportを自らのオープンソース活動の一部として紹介し、公開リポジトリでコードを検証可能にしている。資料は認証制度、調達要件、実運用のバリデーターだとは述べていない。本稿が扱うのはインシデントではなく、テスト選択の来歴である。

結果の前に選択受領票を置く

最小限の改善は、ファイルシステム確認の前に受領票を作ることだ。生の引数、正規化したカテゴリーとテストのトークン、展開した全組み合わせを記録する。各セルに exists と execute または absent-path の処置を付け、実行後に TESTID と既存4結果の一つを結び付ける。

受領票は不在を誤りと断定しない。意図的な疎行列、入力ミス、古い名前、カテゴリーに適用されないテストを区別できるようにするだけだ。自動化も、要求数、存在数、実行数、報告数をそれぞれ照合できる。

4種類の結果は「シナリオが何を返したか」を答える。その前段で必要なのは、「要求した各セルをどう扱ったか」という別の答えである。