From f20b2a79269a0d826d6c5c49df40a98814368b05 Mon Sep 17 00:00:00 2001 From: pi Date: Tue, 4 Aug 2026 18:06:34 +0200 Subject: [PATCH] ci(lint): don't re-lint on tag pushes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `on: push:` with no filter also fires on refs/tags/v*, which is duplicate work: the tagged tree was already linted when that same commit was pushed to main (v1.6.4 sha e86e5df linted as id=529 on main, then again as id=531 on the tag). Two costs beyond the wasted run. It consumed one of the two self-hosted runners while the release pipeline wanted both for its parallel multi-arch variant builds; and it made release-run discovery ambiguous, since the newest-first runs listing puts the tag-ref lint run above the publish run. `branches: ['**']` keeps the documented intent exactly — lint fires early on every branch push and PR, rather than only at tag time — while excluding tag refs. docker-publish.yml is untouched and still tag-scoped. --- .gitea/workflows/lint.yml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/.gitea/workflows/lint.yml b/.gitea/workflows/lint.yml index 69048a8..51348ed 100644 --- a/.gitea/workflows/lint.yml +++ b/.gitea/workflows/lint.yml @@ -6,11 +6,25 @@ name: Lint # actionlint runs shellcheck against each `run:` step using its *effective* # shell, so `set -o pipefail` under dash is flagged as SC3040 before any # expensive build runs. This is cheap (~10s) and independent of the build -# pipeline, so it fires on every push/PR — not just on release tags, which -# is where the build workflow (docker-publish.yml) is otherwise only +# pipeline, so it fires on every branch push/PR — not just on release tags, +# which is where the build workflow (docker-publish.yml) is otherwise only # triggered. +# +# `branches: ['**']` (rather than a bare `push:`) deliberately EXCLUDES tag +# pushes. A bare `push:` also fires on `refs/tags/v*`, which was pure duplicate +# work — the tagged tree was already linted when the same commit was pushed to +# main (v1.6.4: lint id=529 on refs/heads/main, then id=531 again on +# refs/tags/v1.6.4, same sha e86e5df). Worse, that duplicate consumed one of the +# two self-hosted runners while the release pipeline wanted both for its +# parallel multi-arch variant builds, and it made release-run discovery +# ambiguous: the runs listing is newest-first, so the tag-ref lint run sorts +# ABOVE the publish run and "first run matching refs/tags/" picks lint — +# which goes green in minutes while the image is still building. See AGENTS.md +# "Gitea API access" for the head_sha-filtered discovery pattern. on: push: + branches: + - '**' pull_request: workflow_dispatch: