From 1453fa4a33894937e519c032e767cacb5c803aa2 Mon Sep 17 00:00:00 2001 From: npeter83 Date: Sun, 20 Sep 2026 19:47:19 +0200 Subject: [PATCH] ci: run the gate on branch pushes only, not on release tags MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A release pushes main and then the v tag, and a bare `on: [push]` treated the tag as a second push of the identical commit — every release ran the whole gate twice to the same verdict (runs #81-#90 are five such pairs). It has to be `branches`, not the `tags-ignore` this obviously wants to be: Gitea's matchPushEvent requires every named filter to match and each one bails on the wrong ref kind, so `tags-ignore` rejects every BRANCH push and silently disables the gate. Measured in go-gitea v1.27.3, where it differs from GitHub. A trigger filter that stops firing is invisible, so the ops `release` now reads the verdict back for the sha it pushed and says so when there is no run for it. --- .gitea/workflows/check.yml | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/.gitea/workflows/check.yml b/.gitea/workflows/check.yml index ee17d5ee..21684623 100644 --- a/.gitea/workflows/check.yml +++ b/.gitea/workflows/check.yml @@ -15,7 +15,25 @@ # `frontend/src/lib/nodeEngine.contract.test.ts` fails this gate if any of them drift apart. name: gate -on: [push, pull_request] +# Branch pushes only. A release pushes `main` and then the `v` tag, and a bare `on: [push]` +# treated the tag as a second push of the IDENTICAL commit — every release ran this whole gate +# twice, to the same verdict, for nothing (runs #81-#90 are five such pairs). `branches: ['**']` +# keeps every branch covered and drops tag refs. +# +# It has to be `branches`, NOT the `tags-ignore` this obviously wants to be. Gitea's matchPushEvent +# requires EVERY named filter to match, and each one bails on the wrong ref kind: `tags-ignore` +# starts with `if !refName.IsTag() { break }`, so a filter meant to skip tags rejects every BRANCH +# push and the gate stops running entirely. `branches` bails the same way on a tag, which is the +# direction we want. (Measured in go-gitea v1.27.3 modules/actions/workflows.go, not assumed — it +# differs from GitHub, where `tags-ignore` alone leaves branches unfiltered.) +# +# If that filter were ever wrong the gate would not run at all — which is why `siftlode release` +# now ends by reading the verdict back for the sha it pushed, and says so out loud when there is +# no run for it. A gate that silently stops running is the failure this repo already lived through. +on: + push: + branches: ["**"] + pull_request: jobs: frontend: