The full workspace + failpoints suite was the slowest PR gate (~15min
warm, up to the 75min cold ceiling) and dominated PR turnaround. Gate the
`test` job with `if: github.event_name != 'pull_request'` so it runs only
on push to `main` (post-merge), on `v*` tags, and on manual
`workflow_dispatch`. `RustFS S3 Integration` needs `test`, so it becomes
push-/dispatch-only by the same cascade.
Drop `Test Workspace` from the required-check list in
branch-protection.json: a required context that never reports on PRs (the
job no longer runs there) would leave every PR permanently pending — the
job-never-reports trap the policy already documents.
Trade-off accepted deliberately (chosen by the maintainer): a regression
the suite would catch now lands on `main` and reddens the post-merge run
instead of being blocked pre-merge, so `main` can briefly break. Mitigations
documented in ci.md: run `cargo test --workspace --locked` locally before
merging non-trivial changes (or trigger the workflow on your branch via
workflow_dispatch), and regenerate openapi.json locally for server/API
changes (the auto-regen step lived in the now-PR-skipped test job).
The fast PR gates remain: Classify Changes, Check AGENTS.md Links, the
AWS-feature build/test, and the two CODEOWNERS checks.
NOTE: an admin must run ./scripts/apply-branch-protection.sh after this
merges, or GitHub keeps requiring the now-unreported Test Workspace context.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The CODEOWNERS required checks blocked every PR — the real root cause was a
name mismatch, compounded by a path filter:
- branch-protection.json required the contexts `CODEOWNERS / drift` and
`CODEOWNERS / noedit` (the GitHub UI "workflow / job-id" display form), but
the jobs report check-run names from their `name:` fields — "CODEOWNERS
matches source" / "CODEOWNERS not hand-edited". The required contexts
therefore never matched any reported check and sat permanently pending.
- The workflow was also path-filtered to CODEOWNERS files, so it didn't even
run for most PRs.
Net effect: with both required checks unsatisfiable, every PR could only land
via admin override (e.g. #140).
Fixes:
- A: drop the `paths:` filter so the workflow runs on every PR and both
required contexts always report.
- name fix: point branch-protection.json at the actual job names verbatim, and
add a doc note that the contexts must equal the job `name:` values.
- B: the `drift` job now re-renders and, on same-repo PRs, auto-commits the
regenerated artifacts back to the branch (mirrors the openapi.json job in
ci.yml); forks / manual runs strict-check instead. Contributors no longer
run the script by hand.
- D: render-codeowners.py also generates a "who owns what" path->owners +
roles table spliced into docs/dev/codeowners.md between markers, so the
human-readable view never drifts. Idempotent; CODEOWNERS output unchanged.
- docs: correct the stale `enforce_admins: true` line (JSON and live are
false).
NOTE: the branch-protection.json change only takes effect after an admin runs
`./scripts/apply-branch-protection.sh` (deliberate manual step, per
docs/dev/branch-protection.md). Until then `main` still requires the old
mismatched contexts, so this PR itself needs an admin-override merge — the last
one that should be necessary.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
