fix(qa): track qa-reresolve-hw-test.sh executable (litclock-dev#682) - #59
Merged
Conversation
`update.sh` Phase 6 runs `chmod +x` over `scripts/*.sh`. This one file was tracked `100644`, so every update on every clock chmod'd it, left the tree dirty, and the NEXT update warned "uncommitted changes detected — will be overwritten by update", promised to overwrite them, and did not. Nothing breaks. The cost is that the one line which should make an operator stop and look fires unconditionally on every device and is wrong every time, which is how a real warning gets trained out of usefulness. Observed on the fleet sentinel against v0.224.0. The mode was correct in the development repo all along and was lost in the port, so this repairs the port rather than changing behaviour: no file content is touched, only the index mode. A sweep of the other `chmod` targets in update.sh found no second instance — every other `scripts/*.sh` is already tracked `100755`. The file is a hardware QA helper invoked as `sudo ./scripts/qa-reresolve-hw-test.sh …`; nothing imports it, no test asserts its mode, and CI does not run it.
kapoorankush
added a commit
that referenced
this pull request
Aug 21, 2026
…opment-side guards (litclock-dev#707) (#61) [Unreleased] carried two ### Changed headings (df01118, #48) — the defect litclock-dev#697 found and litclock-dev#698 fixed in the development repo, never ported here. Running the ported guard flagged a second live instance: the RELEASED [v0.212.0] section had duplicate ### Fixed and ### For contributors headings unnoticed the whole time. Both merged, every bullet byte-preserved (verified programmatically), no update card any owner has seen can change (cards read the file at the release tag's ref). Two guards arrive: tests/test_changelog_structure.py (no ## section may repeat a ### subheading; fence-aware, tab-tolerant, raises on an unterminated fence) and the chmod/tracked-mode parity guard in tests/test_update_sh.py (litclock-dev#682) — every file update.sh chmods must be tracked executable, or every update on every device re-dirties the tree and the 'Uncommitted changes detected' warning becomes permanent noise. That is the defect that reached a field device via this repo's v0.224.0 (qa-reresolve-hw-test.sh, tracked 100644, symptom fixed in #59 with nothing to stop a recurrence until now). Guard inventory derives from update.sh's actual chmod lines, fails closed on unclassified lines, matches globs as bash would, and reads modes from the index, not the filesystem. Docstrings localized to this repo's history per pre-PR review. Three mutants killed here: the exact #682 mode regression, an unclassifiable chmod line, and a reintroduced duplicate heading.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tracked as litclock-dev#682. Mode-only: no file content changes.
What happens today
update.shPhase 6 runschmod +x "$INSTALL_DIR"/scripts/*.sh.scripts/qa-reresolve-hw-test.shwas tracked100644, so every update on every clock chmod'd it and left the tree dirty — and the next update then printed:promised to overwrite them, and did not. The state is self-perpetuating and self-referential: the update creates the dirt, and the following update warns the operator about it.
Nothing breaks. The cost is that the one line which should make an operator stop and look fires unconditionally on every device in the field and is wrong every time — which is how a real warning gets trained out of usefulness. Observed on the fleet sentinel against v0.224.0.
Why it is a one-line fix and not a behaviour change
The mode was correct in the development repo all along and was lost in the port. This repairs the port.
git show --summaryismode change 100644 => 100755, and the raw diff shows the same blob on both sides (01d1adfa → 01d1adfa).A sweep of the other
chmodtargets found no second instance: every other directscripts/*.shis already tracked100755. (The glob is direct children only —scripts/lib/*.shis not a target.)Checked
sudo ./scripts/qa-reresolve-hw-test.sh …, which in fact requires the bit; nothing imports it, no test asserts its mode, and CI does not run it.pytest tests/— 3455 passed, 62 skipped.One thing worth knowing if you ever redo this by hand:
git update-index --chmod=+xalone is not enough. A latergit add -Are-reads the worktree bit and silently reverts the staged mode. Both the worktree bit and the index are set here.Follow-up that is not in this PR
The development repo has a guard that fails if any file
update.shchmods is tracked non-executable — an inventory of everychmodline plus a classifier, about 150 lines. It has not been ported yet and belongs to the normal port train rather than to this repair.