.gitea/workflows/check.yml previously triggered only on push to main
and pull requests against main. Since every unit is a PR based on next, and next is pushed on each squash-merge, no unit PR and no
push to next ever ran CI — the milestone PR from next to main was
the first place a broken next would surface. This adds next to both
the push and pull_request branch lists.
Nothing else in the workflow changes: the pinned actions/checkout sha
and the script/cibuild step are untouched.
Because this PR's base is next, the CI run it triggers on itself is
the proof the new trigger works.
README's Entrypoints section (script/cibuild bullet) now states in one
sentence where CI runs; TODO.md's Completed Steps log records the
change. TODO.md's Next Step is left as the owner's 1.0.0 scope
decision, which this issue does not touch.
Gate: make check green (tests, containerised lint — 0 issues, format
check).
Disclosure (judgement call): the README previously said nothing about
where the check workflow runs, so DoD point 4's condition ("if it
currently says anything that contradicts this") was not met; I added the
sentence anyway, as the point names it, placing it on the script/cibuild
bullet rather than rewriting the stale main-based development-workflow
list, which is out of scope.
Model: opus-4-8
Closes [issue #122](https://git.eeqj.de/sneak/vaultik/issues/122).
`.gitea/workflows/check.yml` previously triggered only on push to `main`
and pull requests against `main`. Since every unit is a PR based on
`next`, and `next` is pushed on each squash-merge, no unit PR and no
push to `next` ever ran CI — the milestone PR from `next` to `main` was
the first place a broken `next` would surface. This adds `next` to both
the push and pull_request branch lists.
Nothing else in the workflow changes: the pinned `actions/checkout` sha
and the `script/cibuild` step are untouched.
Because this PR's base is `next`, the CI run it triggers on itself is
the proof the new trigger works.
README's Entrypoints section (`script/cibuild` bullet) now states in one
sentence where CI runs; `TODO.md`'s Completed Steps log records the
change. `TODO.md`'s `Next Step` is left as the owner's 1.0.0 scope
decision, which this issue does not touch.
Gate: `make check` green (tests, containerised lint — 0 issues, format
check).
Disclosure (judgement call): the README previously said nothing about
where the check workflow runs, so DoD point 4's condition ("if it
currently says anything that contradicts this") was not met; I added the
sentence anyway, as the point names it, placing it on the `script/cibuild`
bullet rather than rewriting the stale `main`-based development-workflow
list, which is out of scope.
Model: opus-4-8
clawbot
added this to the 1.0.0 milestone 2026-09-21 09:34:15 +02:00
check.yml ran only on push to main and pull_request against main. Under
the current workflow every unit is a PR based on next, and next is
pushed to on each squash-merge, so neither got a CI run; the milestone
PR from next to main was the first place a broken next would surface.
Add next to both the push and pull_request branch lists so unit PRs and
next itself are checked. The workflow is otherwise unchanged: same
pinned actions/checkout sha, same script/cibuild step. README's
Entrypoints section and TODO.md's log record where CI now runs.
Model: opus-4-8
CI red disclosure: the pull_request run on this PR (base next) fired, which is the proof the new trigger works — but the job itself is red because the runner (mac-studio) failed setting up the Docker network with no space left on device, before any check step ran. That is a runner disk-full condition, unrelated to this one-line workflow change; the local gate (make check) is green. Re-running the job once the runner has disk space should pass. Runner disk is the owner's/operator's to clear.
Model: opus-4-8
CI red disclosure: the `pull_request` run on this PR (base `next`) fired, which is the proof the new trigger works — but the job itself is red because the runner (`mac-studio`) failed setting up the Docker network with `no space left on device`, before any check step ran. That is a runner disk-full condition, unrelated to this one-line workflow change; the local gate (`make check`) is green. Re-running the job once the runner has disk space should pass. Runner disk is the owner's/operator's to clear.
Model: opus-4-8
PASS — the two-line trigger addition to .gitea/workflows/check.yml (adding next to the push and pull_request branch lists) matches the definition of done exactly, the pinned actions/checkout sha and script/cibuild step are untouched, the README Entrypoints sentence is accurate, the commit title closes the issue and carries the model line with no attribution trailers, a check / check (pull_request) run fired on this next-based PR head (the proof the trigger works; its red result is a disclosed runner disk-full condition unrelated to the change), and the local gate is green.
Model: opus-4-8
PASS — the two-line trigger addition to `.gitea/workflows/check.yml` (adding `next` to the push and pull_request branch lists) matches the definition of done exactly, the pinned `actions/checkout` sha and `script/cibuild` step are untouched, the README Entrypoints sentence is accurate, the commit title closes the issue and carries the model line with no attribution trailers, a `check / check (pull_request)` run fired on this next-based PR head (the proof the trigger works; its red result is a disclosed runner disk-full condition unrelated to the change), and the local gate is green.
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.
Closes issue #122.
.gitea/workflows/check.ymlpreviously triggered only on push tomainand pull requests against
main. Since every unit is a PR based onnext, andnextis pushed on each squash-merge, no unit PR and nopush to
nextever ran CI — the milestone PR fromnexttomainwasthe first place a broken
nextwould surface. This addsnextto boththe push and pull_request branch lists.
Nothing else in the workflow changes: the pinned
actions/checkoutshaand the
script/cibuildstep are untouched.Because this PR's base is
next, the CI run it triggers on itself isthe proof the new trigger works.
README's Entrypoints section (
script/cibuildbullet) now states in onesentence where CI runs;
TODO.md's Completed Steps log records thechange.
TODO.md'sNext Stepis left as the owner's 1.0.0 scopedecision, which this issue does not touch.
Gate:
make checkgreen (tests, containerised lint — 0 issues, formatcheck).
Disclosure (judgement call): the README previously said nothing about
where the check workflow runs, so DoD point 4's condition ("if it
currently says anything that contradicts this") was not met; I added the
sentence anyway, as the point names it, placing it on the
script/cibuildbullet rather than rewriting the stale
main-based development-workflowlist, which is out of scope.
Model: opus-4-8
CI red disclosure: the
pull_requestrun on this PR (basenext) fired, which is the proof the new trigger works — but the job itself is red because the runner (mac-studio) failed setting up the Docker network withno space left on device, before any check step ran. That is a runner disk-full condition, unrelated to this one-line workflow change; the local gate (make check) is green. Re-running the job once the runner has disk space should pass. Runner disk is the owner's/operator's to clear.Model: opus-4-8
PASS — the two-line trigger addition to
.gitea/workflows/check.yml(addingnextto the push and pull_request branch lists) matches the definition of done exactly, the pinnedactions/checkoutsha andscript/cibuildstep are untouched, the README Entrypoints sentence is accurate, the commit title closes the issue and carries the model line with no attribution trailers, acheck / check (pull_request)run fired on this next-based PR head (the proof the trigger works; its red result is a disclosed runner disk-full condition unrelated to the change), and the local gate is green.Model: opus-4-8
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.