ci(lint): don't re-lint on tag pushes
Lint / hadolint (push) Successful in 9s
Lint / actionlint (push) Has been cancelled

`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.
This commit is contained in:
pi
2026-08-04 18:06:34 +02:00
parent 66a19aa394
commit f20b2a7926
+16 -2
View File
@@ -6,11 +6,25 @@ name: Lint
# actionlint runs shellcheck against each `run:` step using its *effective* # actionlint runs shellcheck against each `run:` step using its *effective*
# shell, so `set -o pipefail` under dash is flagged as SC3040 before any # 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 # 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 # pipeline, so it fires on every branch push/PR — not just on release tags,
# is where the build workflow (docker-publish.yml) is otherwise only # which is where the build workflow (docker-publish.yml) is otherwise only
# triggered. # 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/<tag>" 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: on:
push: push:
branches:
- '**'
pull_request: pull_request:
workflow_dispatch: workflow_dispatch: