fix(texlive-tags): declare the two registry-less references - #172
Conversation
The audit reported 25 drifting references for 2026e while grep found 29. Four sat outside the declaration because they name the image without the registry prefix, which invariants.coverage says the default detection does not reach. Two of those four should be caught. Dockerfile:8 in latex-release-action annotates the same image its first line pins, so when only one of the pair moves the note stops describing what the file builds. ECOSYSTEM.md:73 is the row below one the existing pattern already covers -- the two differ only in whether the name and the tag share a cell, and half of that table was invisible to the audit. The other two stay out, and stay out correctly: CHANGELOG.md records what each release shipped, and ECOSYSTEM.md:330 illustrates the versioning scheme rather than naming the current release. The first needs an explicit ignore because the short-form pattern reaches it -- both its 2026d and its 2026a line -- while the second carries no image name and is excluded by either pattern. Both patterns use a negative lookbehind so the default detection and these do not count the same line twice. Refs #164
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| ], | ||
| "ignore_note": "どのリリースが何を出したかの記録。2026d と 2026a を名乗る行があるが、現行版に揃えると履歴が壊れる。", | ||
| "extra_patterns": [ | ||
| "(?<!ghcr\\.io/smkwlab/)texlive-ja-textlint:\\K[0-9]{4}[a-z]?" |
There was a problem hiding this comment.
🚨 [HIGH] extra_patterns の重複リスク
latex-release-action と latex-ecosystem の両方に同一パターン (?<!ghcr\.io/smkwlab/)texlive-ja-textlint:\K[0-9]{4}[a-z]? が追加されています。
PR 本文では「否定後読みで重複を防ぐ」と説明されていますが、それは同一リポジトリ内での既定検出との重複を防ぐものです。もし将来、両リポジトリが同じファイルを参照するような構成変更があった場合、このパターン自体が複数エントリに存在することで混乱を招く可能性があります。
また、このパターンが latex-release-action の CHANGELOG.md に対しても適用されるかどうか（ignore リストが extra_patterns にも効くか）を、スクリプト側で明示的に保証しているか確認が必要です。もし ignore が extra_patterns に適用されない実装であれば、CHANGELOG.md 内の texlive-ja-textlint:2026d のような行が誤検出される恐れがあります。
There was a problem hiding this comment.
2 点とも確認しました。どちらも据え置きます。
ignore は extra_patterns にも効きます
ご指摘の懸念が一番重要でしたが、audit-texlive-tags.sh の処理順がこうなっています。
ignore=$(printf '%s' "$spec" | jq -r '.ignore // [] | .[]')
hits=$( ... 既定の検出 ... ) # ① 既定検出を集める
extra=$(printf '%s' "$spec" | jq -r '.extra_patterns // [] | .[]')
while IFS= read -r pattern; do
found=$( ... grep -oHnP "$pattern" ... )
[ -n "$found" ] && hits=$(printf '%s\n%s' "$hits" "$found") # ② extra も同じ hits へ
done <<EOF
$extra
EOF
while IFS= read -r hit; do # ③ hits 全体に ignore を適用
file=${hit%%:*}
ignored=false
while IFS= read -r path; do
[ "$file" = "$path" ] && ignored=true
done <<EOF
$ignore
EOF
[ "$ignored" = true ] && continue既定検出と extra_patterns の結果は同じ hits に集約され、除外はその後に一度だけ適用されます。 実装コメントにも設計意図が明記されています。
除外パスは grep の後で落とす。git ls-files に渡して絞ると、宣言したパスが消えていても気付けない
したがって CHANGELOG.md は、パターンが到達しても後段で確実に落ちます。誤検出は起きません。
同一パターンが 2 エントリにある件
宣言はリポジトリごとに独立して適用されます。スクリプトは各リポジトリを個別に clone し、その作業ディレクトリで git ls-files と grep を走らせるため、latex-release-action のパターンが latex-ecosystem のファイルに当たることはありません。
「両リポジトリが同じファイルを参照する構成変更」は、この仕組みでは起こりえない形です。パターンが同じ文字列であることは偶然ではなく、同じ書き方（レジストリ接頭辞なしのイメージ参照）を拾いたいという同じ要求から来ています。共通化するとしたら宣言の構造自体を変える話になり、この PR の範囲を超えます。
| "ignore": [ | ||
| "CHANGELOG.md" | ||
| ], | ||
| "ignore_note": "どのリリースが何を出したかの記録。2026d と 2026a を名乗る行があるが、現行版に揃えると履歴が壊れる。", |
There was a problem hiding this comment.
ignore_note と extra_patterns_note はスキーマ上の正式フィールドか確認を
ignore_note および extra_patterns_note はコメント代わりに使われていますが、JSON にはコメント構文がないためこのアプローチ自体は理解できます。ただし、これらのフィールドがスキーマや処理スクリプト側で「未知フィールドとして無視される」ことが保証されているか確認してください。スキーマ検証が厳格（additionalProperties: false 相当）な場合、バリデーションエラーになる可能性があります。
There was a problem hiding this comment.
スキーマ検証は存在しないので、バリデーションエラーにはなりません。 据え置きます。
audit-texlive-tags.sh が jq で読むフィールドはこれだけです。
.image
.name
.ignore
.extra_patterns
.source_of_truth.repo
.source_of_truth.path
ignore_note と extra_patterns_note は読まれず、単に無視されます。スクリプト内に $schema / ajv / jsonschema 等による検証は一切ありません。
そもそもこの書き方はこのファイルの既存の慣習です。
- トップレベルの
$schema-note— ファイル全体の趣旨を書いている invariants— 5 つの不変条件を散文で書いているlatex-ecosystemのignore_note/extra_patterns_note— 今回追加したものと同じ形
つまり _note サフィックスは、JSON にコメント構文がないことへの既定の対処としてこのファイルが元から採っている方式で、今回それに倣っただけです。ご指摘のとおり additionalProperties: false のスキーマが後から導入されれば影響しますが、そのときは既存の $schema-note や invariants も同時に引っかかるので、このファイル全体の設計判断として扱うべき話になります。
レビュー対応HIGH 1 件・MEDIUM 1 件、いずれも実装を確認して据え置きました。コード変更はありません。CI は HIGH:
|
1 participant
Resolves #164
2026e の drift 是正（#161）で、監査が 25 件を報告した一方 grep では 29 箇所ありました。差の 4 件はレジストリ接頭辞を伴わない short-form で、
invariants.coverageのとおり既定の検出が届きません。うち 2 件は拾うべきものでした。拾うべき 2 件
latex-release-action/Dockerfile:8latex-ecosystem/ECOSYSTEM.md:73拾ってはいけない 2 件
CHANGELOG.mdは各リリースが何を出したかの記録、ECOSYSTEM.md:330はバージョニング方式の例示です。前者には明示的な
ignoreが必要でした。 short-form パターンが届いてしまうためで、しかも検証中に2026d（6 行目）だけでなく2026a（11 行目）もあることが分かりました。後者はイメージ名を伴わないため、どちらのパターンでも自然に除外されます。実測で検証しました
否定後読みを入れた理由
#164 に「既定検出と二重に当たると drift 件数が水増しされるはず」と書いた懸念への対応です。
hitsは既定検出とextra_patternsの結果を単純連結しているので、同じfile:line:tagが 2 回出ると件数が狂います。上の実測どおり、否定後読みでdocs/MULTI-ORG-DEPLOYMENT.md:170が除外され重複しません。効果の確認方法
現在すべて 2026e に揃っているため、今 audit を走らせても drift 0 件で、この変更の効果は見えません。次のリリース（2026f）で
Dockerfile:8とECOSYSTEM.md:73が drift として報告されるかどうかが実証になります。