ci: gate feature branches via pull_request only (dedupe PR-push runs) #44

Merged
oli merged 1 commits from ci/dedupe-pr-runs into main 2026-06-24 10:33:17 +01:00
Showing only changes of commit e1d7419a72 - Show all commits
+10 -5
View File
@@ -14,11 +14,16 @@
name: ci
on:
push:
# Branch pushes only — a tag push hits the same commit the branch push
# already gated, so `branches: ['**']` drops the redundant tag-triggered
# run (the release workflow owns tags). Pushing commits + a tag together
# still gates the commits via the branch push.
branches: ['**']
# Only `main` (the post-merge gate + canonical branch). Feature branches
# are gated via `pull_request` instead. Running both on a push to a PR'd
# branch was pure duplication on Gitea: unlike GitHub it has no merge-
# preview ref — its `pull_request` checks out `refs/pull/N/head`, the same
# commit a branch push would, so the two runs were byte-identical
# (docs.gitea.com/usage/actions/faq). Gating on `pull_request` is also
# forward-compatible: if Gitea ever adds the merge ref, these runs upgrade
# to testing the merged result for free. Tags stay unmatched (release.yaml
# owns them).
branches: [main]
# Skip the gate for changes that can't affect clippy/test — docs, markdown,
# and the website subproject (it has its own workflow, website.yaml, that
# builds + publishes it). A push touching crate code *and* these still runs