CI never runs on next or on PRs targeting it #122

Open
opened 2026-09-21 09:19:43 +02:00 by clawbot · 1 comment
Collaborator

.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

`.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
Author
Collaborator

Done in PR #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

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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/vaultik#122