register-referentie

eho/register-referentie

Fork 0

Author	SHA1	Message	Date
not	f4b41aca84	ci: run verify-stack only on push to main, not on PRs (refs #182 ) (#184 ) CI / k8s (push) Successful in 8s Details CI / build (push) Successful in 1m40s Details CI / lint (push) Successful in 1m53s Details CI / unit (push) Successful in 1m46s Details CI / frontend (push) Successful in 2m35s Details Deploy to Talos / deploy (push) Successful in 2m27s Details CI / mutation (push) Successful in 4m52s Details CI / verify-stack (push) Successful in 12m31s Details ## 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)Reviewed-on: #184	2026-09-25 13:00:26 +00:00

Author

SHA1

Message

Date

not

f4b41aca84

ci: run verify-stack only on push to main, not on PRs (refs #182 ) (#184 )

CI / k8s (push) Successful in 8s

Details

CI / build (push) Successful in 1m40s

Details

CI / lint (push) Successful in 1m53s

Details

CI / unit (push) Successful in 1m46s

Details

CI / frontend (push) Successful in 2m35s

Details

Deploy to Talos / deploy (push) Successful in 2m27s

Details

CI / mutation (push) Successful in 4m52s

Details

CI / verify-stack (push) Successful in 12m31s

Details

## 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)Reviewed-on: #184

2026-09-25 13:00:26 +00:00

Compare commits

Diff Content Not Available