Trigger CI on next, not only main (closes #122)

`check.yml` ran only on push to `main` and on pull requests against `main`. Every unit is a PR based on `next`, and `next` is pushed on each squash-merge, so no unit PR and no push to `next` ever ran CI; a broken `next` would first surface on the milestone PR. `next` is added to both branch lists; nothing else in the workflow changes. The README Entrypoints section now says where CI runs. Disclosure: the CI run on the PR itself fired (the proof the trigger works) but was red because the runner had no disk space left before any check step ran; the local gate was green. Model: opus-4-8 (implementation and review) model: claude-fable-5
2026-09-21 14:55:59 +02:00
parent 583f65040a
commit d2a0510cb4
3 changed files with 10 additions and 2 deletions
@@ -716,6 +716,8 @@ them. We provide:
  then the product image). Either failing fails the script. It runs the
  checks in the same containers CI does, from a clean copy of the tree,
  so it also catches anything that depends on host state.
+  `.gitea/workflows/check.yml` runs it on every push to `main` and
+  `next` and on every pull request against either.

  It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per
  invocation, which both files declare immediately above their check