Claim
The Lockfile Drift Detect workflow in standards (script scripts/check-lockfile-drift.sh) has three reporting defects that made its one and only run (32892897832, 2026-08-25) permanently unactionable — the run behind the now-closed #639:
- Anonymization: every repo is written to
drift-report.tsv as _w — findings can never be traced to a repo.
- Banner miscount: the summary counts
[drift] clean banner lines as drift entries (wc -l − 1 over a file that mixes banners and rows) — "16 entries" was actually 13 rows.
- Error-as-drift: the workflow increments its
drifted counter on any nonzero script exit, so a script error (zero rows emitted) is reported as a drifted repo.
Additionally it has only ever run once — there is no schedule, so drift detection is not actually happening.
Also worth handling in the fix
The one genuine surviving finding from that run: hypatia's tests.yml pins checkout by SHA (34e11487…) while its actions.lock records the same release as v7.0.1 — a tag-vs-SHA representation mismatch of the same release. Survivable (documented in the script's own header), but it defeats exact-match drift detection for that entry; the comparator should resolve tags to SHAs before comparing.
First step
Fix the TSV writer to record the repo slug, count only data rows, and separate error from drifted in the summary; then give the workflow a schedule (weekly is plenty given lockfile churn).
Filed from the #639 verification (2026-08-31) so that issue could close honestly; this one is the actionable remainder.
Claim
The
Lockfile Drift Detectworkflow in standards (scriptscripts/check-lockfile-drift.sh) has three reporting defects that made its one and only run (32892897832, 2026-08-25) permanently unactionable — the run behind the now-closed #639:drift-report.tsvas_w— findings can never be traced to a repo.[drift] cleanbanner lines as drift entries (wc -l − 1over a file that mixes banners and rows) — "16 entries" was actually 13 rows.driftedcounter on any nonzero script exit, so a script error (zero rows emitted) is reported as a drifted repo.Additionally it has only ever run once — there is no schedule, so drift detection is not actually happening.
Also worth handling in the fix
The one genuine surviving finding from that run: hypatia's
tests.ymlpins checkout by SHA (34e11487…) while its actions.lock records the same release asv7.0.1— a tag-vs-SHA representation mismatch of the same release. Survivable (documented in the script's own header), but it defeats exact-match drift detection for that entry; the comparator should resolve tags to SHAs before comparing.First step
Fix the TSV writer to record the repo slug, count only data rows, and separate
errorfromdriftedin the summary; then give the workflow a schedule (weekly is plenty given lockfile churn).Filed from the #639 verification (2026-08-31) so that issue could close honestly; this one is the actionable remainder.