.gitea/workflows/check.yml runs on push to main and on pull_request against main only. Under the current workflow every unit is a PR whose base is next, and next itself is pushed to on every squash-merge; neither triggers CI. So the only branch that gets a CI run is the one nobody commits to directly, and the milestone PR from next to main is the first place a broken next would show up. Right now every "CI green" a reviewer relies on for a unit PR is a local run.
Definition of done
check.yml triggers on push to main and next, and on pull_request against main and next.
Nothing else in the workflow changes; the pinned actions/checkout sha and script/cibuild stay as they are.
The PR for this issue shows a CI run on itself (its base is next), which is the proof the trigger works.
README.md's development-workflow or Entrypoints section says in one sentence where CI runs, if it currently says anything that contradicts this.
Model: fable-5-1
`.gitea/workflows/check.yml` runs on `push` to `main` and on `pull_request` against `main` only. Under the current workflow every unit is a PR whose base is `next`, and `next` itself is pushed to on every squash-merge; neither triggers CI. So the only branch that gets a CI run is the one nobody commits to directly, and the milestone PR from `next` to `main` is the first place a broken `next` would show up. Right now every "CI green" a reviewer relies on for a unit PR is a local run.
## Definition of done
1. `check.yml` triggers on `push` to `main` and `next`, and on `pull_request` against `main` and `next`.
2. Nothing else in the workflow changes; the pinned `actions/checkout` sha and `script/cibuild` stay as they are.
3. The PR for this issue shows a CI run on itself (its base is `next`), which is the proof the trigger works.
4. `README.md`'s development-workflow or Entrypoints section says in one sentence where CI runs, if it currently says anything that contradicts this.
Model: fable-5-1
clawbot
added this to the 1.0.0 milestone 2026-09-21 09:19:43 +02:00
.gitea/workflows/check.yml now triggers on push to main and next and on pull requests against main and next; nothing else in the workflow changed (same pinned actions/checkout sha, same script/cibuild step). README's Entrypoints section (script/cibuild bullet) gains one sentence saying where CI runs; TODO.md's Completed Steps records the change, with Next Step left as the owner's 1.0.0 scope decision.
The PR triggered a pull_request CI run on itself, which is the proof the new trigger fires. That run is currently red for an unrelated reason — the runner failed Docker network setup with no space left on device before any check ran; the local gate (make check) is green. Detail is on the PR.
Model: opus-4-8
Done in [PR #127](https://git.eeqj.de/sneak/vaultik/pulls/127) (base `next`).
`.gitea/workflows/check.yml` now triggers on push to `main` and `next` and on pull requests against `main` and `next`; nothing else in the workflow changed (same pinned `actions/checkout` sha, same `script/cibuild` step). README's Entrypoints section (`script/cibuild` bullet) gains one sentence saying where CI runs; `TODO.md`'s Completed Steps records the change, with `Next Step` left as the owner's 1.0.0 scope decision.
The PR triggered a `pull_request` CI run on itself, which is the proof the new trigger fires. That run is currently red for an unrelated reason — the runner failed Docker network setup with `no space left on device` before any check ran; the local gate (`make check`) is green. Detail is on the PR.
Model: opus-4-8
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.
.gitea/workflows/check.ymlruns onpushtomainand onpull_requestagainstmainonly. Under the current workflow every unit is a PR whose base isnext, andnextitself is pushed to on every squash-merge; neither triggers CI. So the only branch that gets a CI run is the one nobody commits to directly, and the milestone PR fromnexttomainis the first place a brokennextwould show up. Right now every "CI green" a reviewer relies on for a unit PR is a local run.Definition of done
check.ymltriggers onpushtomainandnext, and onpull_requestagainstmainandnext.actions/checkoutsha andscript/cibuildstay as they are.next), which is the proof the trigger works.README.md's development-workflow or Entrypoints section says in one sentence where CI runs, if it currently says anything that contradicts this.Model: fable-5-1
Done in PR #127 (base
next)..gitea/workflows/check.ymlnow triggers on push tomainandnextand on pull requests againstmainandnext; nothing else in the workflow changed (same pinnedactions/checkoutsha, samescript/cibuildstep). README's Entrypoints section (script/cibuildbullet) gains one sentence saying where CI runs;TODO.md's Completed Steps records the change, withNext Stepleft as the owner's 1.0.0 scope decision.The PR triggered a
pull_requestCI run on itself, which is the proof the new trigger fires. That run is currently red for an unrelated reason — the runner failed Docker network setup withno space left on devicebefore any check ran; the local gate (make check) is green. Detail is on the PR.Model: opus-4-8