randomparity / randomparity/kdive
Nothing verifies a push: the full suite is manual and three just ci recipes gate nothing
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
## Problem
Commit-time verification is fast and well covered. Push-time verification does not exist. The
full suite runs only when a person or an agent remembers to type `just ci`, and the post-push
safety net has three holes of its own — so a change can reach `main` without any of the three
ever having run.
The fast inner loop is not the problem and should not change. `just test-lf` and
`just test-changed` (#1334) do their job. What is missing is the gate between "iterating
quickly" and "pushing upstream".
## Evidence
**Nothing runs at push time.**
- `justfile:91-93` — the `install-hooks` recipe runs bare `prek install`, which installs the
`pre-commit` hook type only. No `--hook-type pre-push` is passed anywhere in the repository.
- `.pre-commit-config.yaml` declares no `stages:` key at all, so all 16 hooks run at the
default pre-commit stage: `ruff-check`, `ruff-format`, `check-added-large-files`,
`check-merge-conflict`, `check-toml`, `check-yaml`, `check-executables-have-shebangs`,
`end-of-file-fixer`, `trailing-whitespace`, `shellcheck`, `shfmt-src`, `actionlint`,
`detect-secrets`, `ty`, `lint-ansible`, `schema-immutable`.
- Every one of those is a linter or formatter. **No hook runs a test.**
**The full gate is manual.**
- `justfile:702` — `just ci` chains 24 recipes ending in `test`. Observed wall-clock is
roughly 15-20 minutes. Nothing invokes it automatically; it is typed by hand.
**Three recipes in that chain gate nothing at all.**
- `justfile:557` `lock-check`, `justfile:476` `lint-workflows`, `justfile:678`
`container-arch-check`.
- `grep -rln 'just ' .github/workflows/` returns no file for any of the three.
- CI invokes recipes individually and never calls `just ci` — `.github/workflows/ci.yml` states
this in 14 separate comments, each explaining that a check added only to `just ci` would not
gate pull requests.
- Consequence: these three gate neither a commit, nor a push, nor a pull request. A broken
`uv.lock`, a zizmor finding, or an ADR-0356 compose/arch-matrix drift can reach `main` today.
## Expected
A push-time gate exists and runs automatically, so that reaching `origin` requires more than
remembering a command. The commit-time loop stays as fast as it is now.
The three recipes that currently gate nothing are covered by something — the push gate, a
workflow, or both.
## Proposed approach
No new tooling is needed. `prek`/`pre-commit` already supports per-stage hooks:
1. Add `stages: [pre-push]` entries for the checks chosen below, and pass
`--hook-type pre-push` in `install-hooks` (`justfile:91-93`) alongside the existing install.
2. Cover `lock-check`, `lint-workflows` and `container-arch-check`. These are the highest
value-per-second candidates: each runs in seconds and each currently gates nothing.
**The open question this issue needs to decide is what the push gate contains.** There is a
real tension here and it should not be glossed over: a pre-push hook that runs the full 15-20
minute `just ci` will be bypassed with `--no-verify`, and a gate that is routinely bypassed is
worse than an honest absence, because it reads as protection while providing none. Candidate
shapes, to be chosen in the PR rather than pre-decided here:
- the three ungated recipes only (seconds, strictly additive coverage);
- those plus `test-changed` (fast, but scoped to changed files, so it is not a full-suite
guarantee);
- the full `just ci` (complete, and the most likely to be bypassed);
- a fast push gate plus a separate enforcement point for the full suite.
Whichever is chosen, the PR should say plainly which of the two goals it achieves — "a full
test completed before pushing upstream" versus "the cheap gates can no longer be skipped" —
rather than implying the stronger one.
## Out of scope
- Changing, slowing or replacing `just test-lf` / `just test-changed`. The fast loop works.
- Reorganizing the existing pre-commit hook set.
- Whether CI should also invoke the three ungated recipes. That is worth doing and may be
folded in if it stays within one pull request, but the push-time gap is the subject here.
## Provenance
Requested by the repository operator on 2026-09-16 while reviewing guardrail coverage. The
three-ungated-recipes finding surfaced during that same review, when a base-refreshed branch
needed re-verification and GitHub Actions turned out not to be a superset of the local gate.
Related, neither a duplicate: #1334 added the fast inner-loop recipes this issue deliberately
leaves alone; #2062 covered pre-commit ordering and CI failure summaries.
Contributor guide
Research direction
Start with justfile:91-93 and 476, 557, 678, 702, then inspect .pre-commit-config.yaml and .github/workflows/ci.yml. Decide which push-time checks are appropriate from the listed candidates and wire coverage for the three ungated recipes. Done means the chosen push gate installs and runs automatically, and the PR states whether it guarantees a full test or only prevents cheap gates from being skipped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, devops, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100