Repository navigation
bug(ci): SSOT Configuration Compliance is red on Dev_new_gui — a baseline entry went stale when #14890 fixed the value #14911
Description
Activity
Fixed and merged as
192a2d12c(PR #14910).Verified in base:
stale entry 'clean_wrong_node_dir.yml|"/opt/autobot/{{ dir_name }}/data' 0 occurrences baseline size 1433 lines (was 1434)Correction to this issue's own framing. It said every open PR inherits a failing required check. That is wrong, and it matters for how the incident is understood.
Dev_new_guihas exactly ten required contexts:smoke-test · code-quality · startup-import-smoke · Unit & Integration Tests No open blocks-merge issues reference this PR · No commit trailers verify-generated-types · migration-matrix · verify-precommit-config · api-wiringSSOT Configuration Complianceis not among them. The red reddened the status display but blocked no merge. Merging over a check that was visibly red was still wrong; the blast radius was smaller than stated.That correction exposes the larger finding, tracked separately. Because
ssot-coverageis not a required context, the hardcoded-value detector, the stale-entry audit, and the no-growth guard are all advisory at the protection layer — their# BLOCKINGcomments describe the step, not the gate. This is the same shape as #14353 (python-suiteis not required either). Promoting it is not a one-liner: the workflow is path-filtered, and per #13388 a path-filtered required check deadlocks PRs on "Expected — Waiting for status"; the repo's existing answer is a required-context shim. Recorded in #14912 as an owner decision.Prevention item 1 in this issue is already satisfied — checked rather than assumed.
ssot-coveragedid run on #14890's own head and did fail there (744df346a, failure, 21:48). The cost already lands on the causing change; only enforcement was missing.Prevention item 2 — the recovery cost — is tracked as #14912: a removal-only
--prune-baselineso a fixed violation can drop its baseline line in one command, plus a failure message that names the command and the entries. Measured justification: 1411 entries covering 776 of 9510 tracked files, so ~8% of the repo is baselined and any PR touching a baselined line pays this cost.
SSOT Configuration Complianceis red onDev_new_guiEvery open PR and every new branch inherits a failing required check until this is fixed.
What happened
#14883 added a blocking stale-baseline audit. #14890 then rewrote
roles/_shared/tasks/clean_wrong_node_dir.ymland eliminated a hardcoded path that was baselined, without removing its baseline line. The audit fails:This is the guard working as designed. Its own message states the rule: an entry naming a path that has moved exempts nothing, silently, and re-permits the value the moment the path comes back.
Root cause of the red base
#14890 was merged while this check was failing on its head. The head sha had moved after an automatic base update, and the check state was read and the merge issued in a single step rather than gating on the result. #14890's content is correct and was independently reviewed; only its baseline bookkeeping was missing.
Fix
Remove the one stale entry. 1434 → 1433 lines, total 1977 → 1976. Verified the value is genuinely gone from the path the entry named, so removal is correct rather than convenient. No rule, threshold, or exemption changes.
Prevention
Two separate gaps, neither of which this issue fixes:
mergeable=truewithstate=blocked, and the block was the review gate, not the failing check.Acceptance
--audit-baselinereports no stale entries onDev_new_guiSSOT Configuration Complianceis green onDev_new_gui