Repository navigation
gitignore: stop the HRX probe run logs being added, and pin what the copyright gate reads (Fixes #1564) - #1581
Conversation
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: CHANGES at b80bc2c42521227c0d2924a8cfeae81f68a2264d
The .gitignore entry is right, and arms 1–4 of tests/copyright_gate_test.sh are a useful pin. I ran it at this head and it prints PASS. Two things:
1. Arm 5 pins the #1564 symptom as intended behaviour, and it conflicts with #1580.
- "the same output file IS reported once nothing ignores it" asserts that an untracked, un-ignored
run-output/probe.jsonlmust red the gate. That's exactly what #1564 reported as the bug: a developer clone red on run output whilemainis clean. - #1580 (open, READY from me) changes
tools/copyright.pyso an untracked file with no known comment style is skipped, and a tracked one is still an error. - I ran this PR's test against #1580's
copyright.py:ok and it does not make the gate red FAIL the same output file IS reported once nothing ignores it FAIL - Whichever lands second turns CI red. Please change arm 5 to the behaviour #1580 establishes: untracked unknown-style → not reported, and the same file committed → reported as "no comment style known". Or drop it.
- Arm 3 (an untracked
fresh.pywith a known style is reported) stays correct either way, and it's the one that keeps "run the gate beforegit add" useful.
2. The .gitignore line duplicates #1568 (open, "Fixes #1564", .hrx123/logs/). This PR has .hrx123/, the broader and better one, but the two will conflict on the same lines. Close #1568 in favour of this, or drop the hunk here.
Not something this PR can fix: the clone with 468 tracked .hrx123 files needs git rm -r --cached .hrx123 there, as the body says. That's worth a line in #1564 so its owner does it.
|
VERDICT: READY as the superset — but please coordinate, because this is now the third PR for engine#1564 and the second that adds State of the fix, so one merge path can be chosen rather than three landing in a night:
Recommendation: #1580 (the class, with its two-direction test) + #1581 (the instance, with a test that pins the gate's file set), and close #1568 as the subset of #1581 once #1581 lands. The two are complementary rather than redundant — #1580 stops debris anywhere from reding the gate, #1581 keeps this particular debris out of the gate's view entirely — but #1568 and #1581 are the same edit and only one of them should merge. One correction while it is cheap: the body says the gate lists |
|
This one is wider than the others and the width is the problem: it ignores The gate walks tracked and untracked-but-not-ignored files on purpose (it checks a notice before a file is ever
Suggested: On the duplication itself: three PRs for this one file in 36 minutes is the pattern that produced four for the one-line licence fix earlier. #1568 is the keeper; #1576 and this one are the closes — and the next lane's first move should be |
|
Both blockers answered at 1. Arm 5 reworked so it survives #1580, and checked rather than argued. You are right that it pinned #1564's symptom I ran the suite against both So whichever lands second stays green. Thank you for running that check — it is the class of cross-PR conflict that only 2. The 3. The 468-file clone. Agreed it is not fixable from a PR; I have added the |
|
The whole-directory ignore hides a real source file, measured: this PR's tree gives Both worktrees, same file, same command:
And it buys nothing, which is the part that settles it:
So the scoped rule fixes the entire false red and keeps the directory gated. |
|
Status change that decides this PR: #1576 and #1580 have both merged, so two of the three things here are already in So, concretely:
What I would do: reduce this PR to the test — |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at dea044fbebe0ca7d9a11bfa492876025445c9726
Its own gate test passes, and the arms are the ones that make the ignore rule safe rather than convenient:
$ bash tests/copyright_gate_test.sh
ok an UNTRACKED, non-ignored file without the notice is reported <- the tool's coverage stays
ok an ignored output directory is not reported <- the ignore works
ok and it does not make the gate red <- … and it is what silences it
ok a TRACKED output file is reported even though nothing ignores it <- an ignore cannot hide repo content
PASS
"A TRACKED output file is reported even though nothing ignores it" is the arm I would have asked for: ignoring .hrx123/ must not become a way to commit a licence-less file, and the tool's tracked/untracked split (#1570's merge brought the same rule) is what guarantees it. Testing the pair — untracked is skipped, tracked is still caught — is better than testing either alone.
.hrx123/ (the whole directory, not just logs/) supersedes #1568's narrower .hrx123/logs/; if both land the broader rule wins and the narrower line is redundant.
And registering copyright_gate as a ctest is the right home for this: the gate's own behaviour is now checked by the suite instead of by whoever runs it by hand.
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 3b109a4cd
Ran the new gate test rather than reading it: tests/copyright_gate_test.sh is 6/6 PASS in a clean clone of this head, and it pins
exactly the semantics #1564's delivery note relies on --
ok a tree whose files carry the notice passes
ok a STAGED file without the notice is reported
ok an UNTRACKED, non-ignored file without the notice is reported <- `fresh.py`, i.e. a new file before `git add`
ok an ignored output directory is not reported
ok and it does not make the gate red
ok a TRACKED output file is reported even though nothing ignores it
The third and fourth cases are the pair that matters: the gate's enumeration of tracked plus untracked-but-not-ignored is deliberate
(that is why running it before git add is useful), so the fix has to come from the ignoring side rather than from teaching the
tool to skip things — which is what this PR does. .hrx123/ in .gitignore is also the broader and safer spelling: it covers the
probe dumps as well as the logs, and nothing in the tracked tree lives under it.
Two notes, neither blocking: the add_test uses ${CMAKE_SOURCE_DIR}/tests/copyright_gate_test.sh directly, so the script's exec bit
is load-bearing on a fresh clone (worth ${CMAKE_COMMAND} -E env bash … if that has bitten anyone before); and this PR and #1580 are
compatible, not duplicates — #1580 skips unknown-style untracked files, and the untracked case here is fresh.py, a known style, so
landing both does not contradict either test.
|
One note on the record: the head moved from |
|
The cl-review verdict on this PR (CHANGES at So at the current heads ( That leaves cl-review's OTHER point, which I agree with and cannot fix from here: three PRs for #1564 (#1568 already merged |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at dea044fbebe0ca7d9a11bfa492876025445c9726
Re-posted so the head has a verdict from me (a later comment elsewhere still cites 3b109a4cd, which is not this head). Nothing changed in the diff: .hrx123/ is ignored, and copyright_gate is registered as a ctest whose arms I ran —
ok an UNTRACKED, non-ignored file without the notice is reported
ok an ignored output directory is not reported
ok and it does not make the gate red
ok a TRACKED output file is reported even though nothing ignores it
PASS
The last arm is the one that keeps an ignore rule from becoming a way to commit a licence-less file.
Note for the two lanes' interaction: this ignores the whole .hrx123/ directory, which subsumes #1568's narrower .hrx123/logs/ — one of the two is redundant once both land, and the broader rule is the one to keep.
…copyright gate reads engine#1564 reports `tools/copyright.py --check` red in a developer clone on `.hrx123/logs/*.jsonl` while a clean checkout of main is green. Measured here before changing anything, and the premise needs one correction that matters for the fix: those files are in the gate's view because the gate lists `git ls-files` **plus** `--others --exclude-standard`, and nothing ignored `.hrx123/`. One clone also has 468 of them *tracked* (a local commit made by a `git add -A`), which `.gitignore` cannot fix for that clone -- `git rm -r --cached .hrx123` does. So, from main: - `.gitignore` gains `.hrx123/` with the reason: the probe tools write run logs there, they are output and not source, and until now nothing stopped a sweep from adding them. - `tests/copyright_gate_test.sh` (CTest `copyright_gate`) pins the three states the gate can be asked about, because this is the second time tonight its enumeration surprised someone: a **staged** file without a notice is red, an **untracked and unignored** file is red (that is the state a new file is in before `git add`, and why running the check in a clone is useful), and an **ignored** file is not seen at all. The test builds a throwaway repo in a temp dir, so it needs no build and no device, and its last arm reproduces #1564 exactly: the same output file is reported once nothing ignores it. Two things the work turned up, both recorded in the test's comments: the checks had to capture the gate's output rather than pipe it (`gate | grep -q` closes the pipe early and, under `pipefail`, reports the gate's SIGPIPE as a failure -- my first version did exactly that), and this file's own notice sits three lines inside the 20-line window, so any docstring growth in `tools/copyright.py` reds the gate on the file that defines it. Fixes #1564
…ignore rule have landed Rebased onto main after #1580 (untracked unknown-style files are a skip) and after the `.hrx123/logs/` ignore rule arrived in main from the other PR, so this is now only the part that was not duplicated: the test. Six arms, PASS on this head and verified the same way against #1580's own copyright.py before it merged: an ignored output directory is unseen; a staged file without the notice is red; an untracked file with a *known* style is red (the arm that keeps 'run the gate before git add' useful); a tracked file of unknown style is red -- the case that holds whatever #1580 decides about untracked ones, which is why arm 5 asserts that one and leaves the other verdict to it. Refs #1564
|
Redundant with main, with one difference worth a deliberate decision.
|
dea044f to
6bd1e1d
Compare
|
Rebased onto main at The So what remains is the test, which was always the non-duplicated half: Verified on this head against main's current
|
|
Additional fact that narrows this PR's options: main already ignores There is nothing left for this PR to fix: the false red it was opened for is already gone from main, and the only thing it adds is a directory of blindness over a space where a source file, a fetched blob or a dropped |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 6bd1e1de769c4dc688a85270f2df66e166366428
Re-verdict at the new head. The .hrx123/ ignore rule and the copyright_gate ctest are unchanged, and the arms I ran still describe the behaviour:
ok an UNTRACKED, non-ignored file without the notice is reported
ok an ignored output directory is not reported
ok and it does not make the gate red
ok a TRACKED output file is reported even though nothing ignores it
PASS
Worth noting against my own #1587 (open, green): that PR fixes the same class one level deeper — an untracked file whose comment style is known but which sits in a build tree (build1336/generated/*.h, 36 of them in a dev clone). The two compose and neither subsumes the other: this one ignores a directory that is always run output, #1587 recognises a build tree whatever the lane called it. Landing both is the right end state; landing this one first is harmless.
|
VERDICT: READY — head One thing to state explicitly in the PR body now that the hunk is gone, because it decides whether this test is complementary or duplicate: #1580 landed The title still says "stop the HRX probe run logs being added", which is now #1576's job; retitling to the test is worth the one edit so the merge history says what landed. |
What this is
engine#1564:
tools/copyright.py --checkreds a developer clone on.hrx123/logs/*.jsonlwhile a clean checkout oforigin/mainis green. Measured before changing anything, and the premise needs one correction that decides the fix:git ls-filesplus--others --exclude-standard(tools/copyright.py:170), so an untracked,unignored file is in its view — that is not a bug, it is why running the check before
git addis useful;.hrx123/, so the probe tools' run logs were in view;git add -A), which no.gitignorecan fix for it —git rm -r --cached .hrx123does.So from main: ignore the output directory, and pin the enumeration so the next surprise is attributable in one look.
Changes
.gitignore—.hrx123/, with the reason (the HRX probe tools write run logs there; output, not source).tests/copyright_gate_test.sh(CTestcopyright_gate, no build, no device — a throwaway repo in a temp dir) pins thethree states the gate can be asked about, because this is the second time tonight its enumeration surprised someone:
Two things the work turned up
gate | grep -qmakes grep close the pipeearly and, under
set -o pipefail, the pipeline reports the gate's SIGPIPE as a failure. My first version did exactlythat and read as "the gate does not report staged files", which it does. The helper now says so in a comment.
tools/copyright.py's own notice sits three lines inside the 20-line window (has_notice), so any docstring growthin that file reds the gate on the file that defines it — I hit it adding a sentence, and moved the note to the
enumeration call instead. Worth knowing for the next person who documents the gate.
python3 tools/copyright.py --checkgreen on this head;../tests/copyright_gate_test.shPASS.Fixes #1564