test: guard declarative coverage of deploy/#114
Conversation
Every deploy/ dimension should name every managed repository. When a repo is created or renamed it is typically added to one or two dimensions and missed in the rest, leaving it partly declared while un-modelled settings drift. Adds a hermetic guard that derives the expected repository set from the union of all dimensions and fails closed on any repo missing from one of them. The 14 pre-existing gaps are exempted explicitly with a tracked reason so the guard lands green and ratchets; a stale exemption also fails. Part of #56
"${arr[@]}" on an empty array is an unbound-variable error under set -u on
bash < 4.4. The exemption list is designed to shrink to empty as #115 closes the
gaps, so that end state must work on every bash, not just the CI runner's.
Readiness record — head
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 960ce57871
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex review (P2 x2): a filename-based check counts a manifest that is not wired into its directory's kustomization.yaml, and a renamed file whose forProvider still names the old repo — both are the partial-add/partial-rename drift this guard exists to catch. Reads kubectl kustomize output instead. This also removes repository-permissions as a dimension: it is deliberately not wired into deploy/kustomization.yaml, so its 4 reported gaps were phantoms. Real gap count 14 -> 10. Also expires an exemption whose repo has left the model (P3), and syncs the PR-validation instructions in AGENTS.md and deploy/README.md (P2).
Review resolution — all four findings fixed in
|
@codex review |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Readiness — pentad clear at
|
| surface | state |
|---|---|
| CI | all green / skipped |
| unresolved threads | 0 (all 4 Codex findings fixed and resolved) |
| conflicts | mergeStateStatus: CLEAN |
| pre-merge checks | not-posted — CodeRabbit never reviewed; consequence of the one-tool-per-PR Codex lane, not a gap |
| green review | Codex green at 502a87a4cb == head |
Held as a draft deliberately. This PR edits AGENTS.md lines 79–81, which sit inside its
## Maintenance section — part of the agent's own definition under the shared contract, and the one
class that keeps the human promotion gate. So it awaits @devantler's promotion; I'll drive it to
merge myself once promoted.
Evaluated as its own user — that is what found the real problems
Running the guard against the tree it governs did more than confirm it:
- It surfaced that
deploy/repository-permissions/is deliberately unwired from
deploy/kustomization.yaml, so the four gaps I originally reported there were phantoms. chore: close the 10 declarative coverage gaps found by the deploy/ coverage guard #115 is
corrected: 14 → 10 real gaps. - The non-vacuity control (emptying the exemption list) failed with
exemptions[@]: unbound variable—"${arr[@]}"on an empty array underset -uon bash < 4.4. That is precisely the
end state this guard ratchets toward, so it would have broken exactly when it finally succeeded.
Every branch RED-proven individually with GREEN restored and a clean tree, including the two cases
the review predicted: a manifest present on disk but unwired (reported missing — the filename-based
version counted it as declared), and an exemption whose repo has left the model.
1 participant
Why
The org's GitHub-as-code model is only trustworthy if "declared in
deploy/" means all of it.Today nothing checks that. When a repository is created or renamed it typically gets added to one
or two parts of
deploy/and quietly missed in the rest — so it looks managed on inspection whileits un-modelled settings drift underneath. Seven repositories are already in that state, and the
only way to notice was to hand-audit the tree.
What
Adds a test that fails CI when a repository is declared in some parts of
deploy/but not others,naming every gap it finds. The seven known gaps are recorded as explicit, tracked exemptions so
this lands green and ratchets forward — new drift fails immediately, and an exemption that is no
longer true also fails, so the list cannot go stale.
Closing the known gaps is deliberately left to follow-up work: repository-settings writes are
currently blocked (#112), and bundling seven policy decisions into a guard would make both harder
to review.
Fixes #113
Part of #56