docs: what a merge to main does, and how to read a cancelled run #108

Merged

jlxq0 merged 1 commit from docs/release-and-ci-facts into main

2026-09-02 02:42:59 +00:00

jlxq0 commented

2026-08-25 02:16:01 +00:00

Owner

Two facts established while merging #107, both of the kind that get assumed
wrong once and then acted on confidently.

A merge to `main` deploys nothing

.forgejo/workflows/ci.yml runs the docker job on any non-pull-request event,
but its step is "Build (and push on tag)", and the GHCR mirror is gated on
refs/tags/v. So a merge builds and validates; it publishes nothing and changes
nothing that is running. Publishing is a v* tag, and that is the deliberate
gate.

It matters more here than in most repositories: this one carries the channel
every agent's inbound Matrix traffic arrives on, so an unintended rollout
would not announce itself in the usual way. The thing that would tell you is the
running image tag, not the merge.

A cancelled run and a failed run look identical from outside

Visible on #107 itself: a newer push landed on the same ref and the earlier run
reads cancelled whatever it was about to do. Two ways that misleads — a run
that had already reached a real failure reads as "superseded", and a version
that never moved reads as "still queued" rather than "never built".

The rule is already recorded in a-grand-tour_ios's AGENTS.md for the same
Forgejo behaviour. It is true here, and this repository had no copy.

Verification

Documentation only. Both claims were read out of .forgejo/workflows/ci.yml
rather than inferred, and the second was observed on this repository's own run
list while merging #107.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SP7njJZ7ZtrMgULuXh8ddq

Two facts established while merging #107, both of the kind that get assumed wrong once and then acted on confidently. ## A merge to `main` deploys nothing `.forgejo/workflows/ci.yml` runs the `docker` job on any non-pull-request event, but its step is **"Build (and push on tag)"**, and the GHCR mirror is gated on `refs/tags/v`. So a merge builds and validates; it publishes nothing and changes nothing that is running. Publishing is a `v*` tag, and that is the deliberate gate. It matters more here than in most repositories: **this one carries the channel every agent's inbound Matrix traffic arrives on**, so an unintended rollout would not announce itself in the usual way. The thing that would tell you is the running image tag, not the merge. ## A cancelled run and a failed run look identical from outside Visible on #107 itself: a newer push landed on the same ref and the earlier run reads `cancelled` whatever it was about to do. Two ways that misleads — a run that had already reached a real failure reads as "superseded", and a version that never moved reads as "still queued" rather than "never built". The rule is already recorded in `a-grand-tour_ios`'s `AGENTS.md` for the same Forgejo behaviour. It is true here, and this repository had no copy. ## Verification Documentation only. Both claims were read out of `.forgejo/workflows/ci.yml` rather than inferred, and the second was observed on this repository's own run list while merging #107. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SP7njJZ7ZtrMgULuXh8ddq

jlxq0 referenced this pull request

2026-08-27 02:01:06 +00:00

docs(agents): why main requires cargo and not docker #131

jlxq0 force-pushed docs/release-and-ci-facts from 3d6df99f96

CI / cargo (pull_request) Successful in 1m51s

Details

CI / docker (pull_request) Has been skipped

Details

to d1856bff8b

CI / cargo (pull_request) Successful in 1m48s

Details

CI / docker (pull_request) Has been skipped