Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Why this directory exists, and the trap it carries
Gitea uses .gitea/workflows if it exists, and falls back to
.github/workflows only when it does not. It never merges them.
So adding one Gitea-only workflow here silently switches off CI — and therefore auto-merge — for the whole repository on Gitea. There is no error and no run to click on. It looks exactly like a runner that has not picked the job up, so you wait, and waiting never fixes it.
Every workflow that must run on Gitea has to be in this directory.
ci.yml and compat.yml are kept byte-identical in both roots, and
ci/workflows-in-sync.sh fails if the two copies drift apart or if a workflow
appears in only one of them without a stated reason.
release.yml is the deliberate exception: a release workflow publishes to
whichever forge runs it, and the two copies publish to different places. The
Gitea one is the one that matters — that is where the update feed shops read
lives.
Two further rules learned the hard way:
- No
concurrency:block in a Gitea workflow. It produces no run at all — not a failed one, not a cancelled one. Same shape of trap, same symptom. - If a Gitea workflow produces no run, suspect the file, not the runner.