verify-stack now runs only on a push to main (a merge), not on pull requests. Every job before it (lint, k8s, build, unit, frontend, mutation) is unchanged and still runs on PRs.
Why: the Gitea runner shares the 15 GB lab node with the deployed stack. verify-stack boots the whole stack a second time inside dind, which is what got the runner OOM-killed (#182). Running it once per merge instead of on every PR push roughly halves how often that happens.
.gitea/workflows/ci.yaml: if: github.event_name == 'push' && github.ref == 'refs/heads/main' on verify-stack, with a comment.
docs/runbooks/ci.md: the job table notes "push to main only".
CI green. This PR's own run should show verify-stack as skipped, which is the check for the PR half.
Docs updated (docs/runbooks/ci.md).
Notes for reviewers
gotchas §7: on Gitea 1.27 + act_runner 2.0.0, a needs job gated by a status-functionif (always()/cancelled()) never leaves waiting. This if is a plain event check, so it keeps the implicit success() and should not hit that path. It's only proven once the first merge to main runs verify-stack. If that run sits in waiting with no logs, force-cancel it and revert this.
Policy change: CLAUDE.md §3/§15 say the compose-up smoke test "runs in CI and gates merges". After this it runs after the merge, so a live-stack break shows up as a red main (P0 per §15) instead of a blocked PR. CLAUDE.md changes need their own issue and PR, so I left it untouched. It should be updated if this approach is kept.
If verify-stack is a required status check in branch protection, remove it there too. Otherwise PRs will wait for a check that never runs.
## What & why
`verify-stack` now runs only on a push to `main` (a merge), not on pull requests. Every job before it (lint, k8s, build, unit, frontend, mutation) is unchanged and still runs on PRs.
**Why:** the Gitea runner shares the 15 GB lab node with the deployed stack. `verify-stack` boots the whole stack a second time inside `dind`, which is what got the runner OOM-killed (#182). Running it once per merge instead of on every PR push roughly halves how often that happens.
- `.gitea/workflows/ci.yaml`: `if: github.event_name == 'push' && github.ref == 'refs/heads/main'` on `verify-stack`, with a comment.
- `docs/runbooks/ci.md`: the job table notes "push to main only".
Refs #182
## Definition of Done
- [x] Linked Gitea issue (above).
- [ ] Failing test first. *(CI config.)*
- [x] Conventional Commits referencing the issue.
- [ ] CI green. **This PR's own run should show `verify-stack` as skipped**, which is the check for the PR half.
- [x] Docs updated (`docs/runbooks/ci.md`).
## Notes for reviewers
- **gotchas §7:** on Gitea 1.27 + act_runner 2.0.0, a `needs` job gated by a *status-function* `if` (`always()`/`cancelled()`) never leaves `waiting`. This `if` is a plain event check, so it keeps the implicit `success()` and should not hit that path. It's only proven once the first merge to `main` runs `verify-stack`. If that run sits in `waiting` with no logs, force-cancel it and revert this.
- **Policy change:** CLAUDE.md §3/§15 say the compose-up smoke test "runs in CI and gates merges". After this it runs *after* the merge, so a live-stack break shows up as a red `main` (P0 per §15) instead of a blocked PR. CLAUDE.md changes need their own issue and PR, so I left it untouched. It should be updated if this approach is kept.
- If `verify-stack` is a required status check in branch protection, remove it there too. Otherwise PRs will wait for a check that never runs.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The runner shares the lab node with the deployed stack; a second full stack
per PR is what got it OOM-killed. PRs keep every other job as the merge gate.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
not
merged commit f4b41aca84 into main2026-09-25 13:00:27 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What & why
verify-stacknow runs only on a push tomain(a merge), not on pull requests. Every job before it (lint, k8s, build, unit, frontend, mutation) is unchanged and still runs on PRs.Why: the Gitea runner shares the 15 GB lab node with the deployed stack.
verify-stackboots the whole stack a second time insidedind, which is what got the runner OOM-killed (#182). Running it once per merge instead of on every PR push roughly halves how often that happens..gitea/workflows/ci.yaml:if: github.event_name == 'push' && github.ref == 'refs/heads/main'onverify-stack, with a comment.docs/runbooks/ci.md: the job table notes "push to main only".Refs #182
Definition of Done
verify-stackas skipped, which is the check for the PR half.docs/runbooks/ci.md).Notes for reviewers
needsjob gated by a status-functionif(always()/cancelled()) never leaveswaiting. Thisifis a plain event check, so it keeps the implicitsuccess()and should not hit that path. It's only proven once the first merge tomainrunsverify-stack. If that run sits inwaitingwith no logs, force-cancel it and revert this.main(P0 per §15) instead of a blocked PR. CLAUDE.md changes need their own issue and PR, so I left it untouched. It should be updated if this approach is kept.verify-stackis a required status check in branch protection, remove it there too. Otherwise PRs will wait for a check that never runs.🤖 Generated with Claude Code