Three comments in the test tree state how many captures under examples/captures/ are committed. All
three are wrong or about to be, and one of them was already wrong before any recent change.
The tracked set is 6 on main — dhcp.pcapng, in.pcap, out.json, out.plist, out.txt,
pcapng.txt — and 2 once #697 lands (dhcp.pcapng, in.pcap), since #697 stops tracking the four
rendered reports for #685.
The three sites
Why this is worth an issue rather than a drive-by
No test asserts any of these numbers, so nothing goes red — which is exactly why they rot. They are
prose that a reader trusts while debugging the tier guard, and the tier guard is the machinery that
decides whether a unit-tier test may read a capture at all. A wrong count there sends someone looking
for two files that are not the two in play.
The underlying code is fine and deliberately so: tests/_tiers.py:293 resolves the set live with
_git('ls-files', '-z', '--', relative_root) and holds no hardcoded list, which is why #697 needs no
change to it — tests/test_tier_guard.py passes 25 tests / 15 subtests against that branch. Only the
prose is wrong.
Suggested fix
Drop the specific numbers rather than updating them, since an updated number rots again on the next
capture. Each of the three can say what it means without a count: "the committed captures" and "the
moment another capture is committed" carry the same information and cannot go stale. Where a count
genuinely helps a reader, derive it in the sentence from the live listing the code already computes.
Related, already fixed by accident
examples/legacy_smoke/README.rst:23-24 claimed "Only in.pcap and dhcp.pcapng are committed",
which was false on main with six tracked and becomes true under #697. No action needed there;
recorded so the accidental fix is not mistaken for an unrelated change when reviewing #697.
Found by the #685 worker while doing #697, outside the files it owned, so it was flagged rather than
fixed.
Three comments in the test tree state how many captures under
examples/captures/are committed. Allthree are wrong or about to be, and one of them was already wrong before any recent change.
The tracked set is 6 on
main—dhcp.pcapng,in.pcap,out.json,out.plist,out.txt,pcapng.txt— and 2 once #697 lands (dhcp.pcapng,in.pcap), since #697 stops tracking the fourrendered reports for #685.
The three sites
tests/_tiers.py:36-37— "a hardcoded list of names silently rots the moment somebody commitsanother capture (there are six today, not the two ...)". Correct on
main; stale after chore(examples): stop tracking the four rendered capture reports (#685) #697,where it is two again. The irony is that the comment is explaining why the code does not hardcode
a list, and the comment itself hardcodes the count.
tests/integration/_helpers.py:58-59— "underexamples/captures/are fixtures -- four of themare committed". This is already wrong on
main, where six are committed. Not stalenessintroduced by chore(examples): stop tracking the four rendered capture reports (#685) #697 — a pre-existing error. It becomes two after chore(examples): stop tracking the four rendered capture reports (#685) #697.
tests/test_tier_guard.py:15— "the moment a seventh capture is committed(
CommittedCaptureTests)". Correct onmainas the next-after-six; becomes "a third" afterchore(examples): stop tracking the four rendered capture reports (#685) #697.
Why this is worth an issue rather than a drive-by
No test asserts any of these numbers, so nothing goes red — which is exactly why they rot. They are
prose that a reader trusts while debugging the tier guard, and the tier guard is the machinery that
decides whether a unit-tier test may read a capture at all. A wrong count there sends someone looking
for two files that are not the two in play.
The underlying code is fine and deliberately so:
tests/_tiers.py:293resolves the set live with_git('ls-files', '-z', '--', relative_root)and holds no hardcoded list, which is why #697 needs nochange to it —
tests/test_tier_guard.pypasses 25 tests / 15 subtests against that branch. Only theprose is wrong.
Suggested fix
Drop the specific numbers rather than updating them, since an updated number rots again on the next
capture. Each of the three can say what it means without a count: "the committed captures" and "the
moment another capture is committed" carry the same information and cannot go stale. Where a count
genuinely helps a reader, derive it in the sentence from the live listing the code already computes.
Related, already fixed by accident
examples/legacy_smoke/README.rst:23-24claimed "Onlyin.pcapanddhcp.pcapngare committed",which was false on
mainwith six tracked and becomes true under #697. No action needed there;recorded so the accidental fix is not mistaken for an unrelated change when reviewing #697.
Found by the #685 worker while doing #697, outside the files it owned, so it was flagged rather than
fixed.