grenadeandClaude Opus 5.5
ec615cac52
deploy.yaml was the only workflow and ran only on main, so a pushed branch started no run at all: the first time CI saw a change was the push that deployed it. And its `mode: validate` input, offered as "check only", was read by no job — a validate dispatch built and deployed whatever ref it ran on. ci.yaml now runs on every branch but main, on the `rust` runner, with no deploy job, no secrets and no artifact. The gate itself moves into a local composite action, .gitea/actions/gate, which both ci.yaml and deploy.yaml's `build` job use, so the gate a branch passes is the gate main runs rather than a copy that can drift. Its commands are CLAUDE.md's "Run the gate CI runs" verbatim. One deliberate change on the way: the drift check is `git status --porcelain`, as CLAUDE.md and #28 state it, not `git diff --quiet`, which cannot see the new untracked file a new DTO generates. Both deploy jobs now require `github.ref == 'refs/heads/main'` and `inputs.mode != 'validate'` (empty on a push, so the push path and its "what changed" gating are unchanged). A validate dispatch on main runs the build and gate plus a new `validate` job: the read-only checks from the end of deploy-api and deploy-web — API health from bob, reachability from the edge, the chain list through the vhost — against what is already deployed. Those checks are copied rather than shared, because the deploy jobs run from the build artifact without a checkout and restructuring them is a change only a production deploy would test; the comment says they must change together. Closes #28 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015pkwBsR54NRmZyU4QVhvfj
36 lines
1.4 KiB
YAML
36 lines
1.4 KiB
YAML
name: ci
|
|
|
|
# The gate, on every branch that is not main. Before this, a branch's only check
|
|
# was whatever its author ran locally, and the first time CI saw a change was the
|
|
# push to main — which is also the deploy (#28).
|
|
#
|
|
# Check only. No deploy job, no `secrets.*`, no artifact: nothing here can reach
|
|
# a host, so a branch cannot ship by being pushed. main is excluded because
|
|
# deploy.yaml runs the same gate there as the first half of the deploy, and
|
|
# running it twice would only race the deploy for a runner.
|
|
#
|
|
# The steps are not written here. They live in .gitea/actions/gate, which the
|
|
# `build` job in deploy.yaml uses too, so a branch that is green here has passed
|
|
# exactly the gate main will run.
|
|
|
|
on:
|
|
push:
|
|
branches-ignore: [main]
|
|
|
|
jobs:
|
|
gate:
|
|
# `rust`, not `fedora-*`: the fedora images have no cargo (gitea-runners.md
|
|
# §4). `runner-rust` is built on `runner-fedora-44`, so node and pnpm are
|
|
# there too and one job runs both halves — the same runner `build` uses.
|
|
runs-on: rust
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
# Always the whole gate. deploy.yaml can skip the Rust half on a
|
|
# frontend-only push because it diffs against what is running on bob; a
|
|
# branch has no such baseline, and a branch is where a stale-types or
|
|
# clippy failure is cheapest to find.
|
|
- uses: ./.gitea/actions/gate
|
|
with:
|
|
rust: "true"
|