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

2026-06-24T10:30:13+01:00

claude-clouddev1 commented

2026-06-24 10:30:13 +01:00

Halves CI on every PR push by gating feature branches through pull_request only.

The problem

A push to a branch with an open PR fires both the push and pull_request triggers, so the whole workflow (gate and manifests) runs twice at the same point — doubling wall-clock on every PR update.

Why it's pure waste on Gitea

On GitHub the two runs differ (the pull_request run builds refs/pull/N/merge, a preview of the merged result; push builds the branch tip). But the Gitea Actions FAQ states Gitea has no merge ref — its pull_request checks out refs/pull/N/head, i.e. the same commit a branch push would. So on Gitea the two runs are byte-identical: genuine duplication, no added coverage.

The change

on:
  push:
    branches: [main]      # was ['**']
  pull_request:           # unchanged — gates every feature branch

Under the ADR-0059 "everything via PR" flow, every feature branch has a PR, so pull_request already covers them; push now only gates main (post-merge) + is unmatched by tags (release.yaml owns those). Net: one run per PR push instead of two, no coverage lost.

Forward-compatible: keeping the gate on pull_request (not push) means that if Gitea ever adds the merge-preview ref, these runs automatically upgrade to testing the merged result — for free. Your up-to-date-before-merge protection already covers the "breaks when merged" case at merge time.

The reasoning + the Gitea-FAQ citation are recorded in an on: push comment in ci.yaml.

Note: this PR still shows the doubled runs — it's gated by the old ['**'] config until it merges; the dedupe takes effect for PRs after it lands. Required check (ci / gate*) still matches the pull_request context, so branch protection is unaffected.

Halves CI on every PR push by gating feature branches through `pull_request` only. ## The problem A push to a branch with an open PR fires **both** the `push` and `pull_request` triggers, so the whole workflow (`gate` *and* `manifests`) runs **twice** at the same point — doubling wall-clock on every PR update. ## Why it's pure waste *on Gitea* On GitHub the two runs differ (the `pull_request` run builds `refs/pull/N/merge`, a preview of the merged result; `push` builds the branch tip). But the [Gitea Actions FAQ](https://docs.gitea.com/usage/actions/faq) states Gitea **has no merge ref** — its `pull_request` checks out `refs/pull/N/head`, i.e. the **same commit** a branch push would. So on Gitea the two runs are byte-identical: genuine duplication, no added coverage. ## The change ```yaml on: push: branches: [main] # was ['**'] pull_request: # unchanged — gates every feature branch ``` Under the ADR-0059 "everything via PR" flow, every feature branch has a PR, so `pull_request` already covers them; `push` now only gates `main` (post-merge) + is unmatched by tags (release.yaml owns those). Net: one run per PR push instead of two, **no coverage lost**. **Forward-compatible:** keeping the gate on `pull_request` (not `push`) means that if Gitea ever adds the merge-preview ref, these runs automatically upgrade to testing the merged result — for free. Your `up-to-date-before-merge` protection already covers the "breaks when merged" case at merge time. The reasoning + the Gitea-FAQ citation are recorded in an `on: push` comment in `ci.yaml`. --- > Note: this PR still shows the doubled runs — it's gated by the old `['**']` config until it merges; the dedupe takes effect for PRs after it lands. Required check (`ci / gate*`) still matches the `pull_request` context, so branch protection is unaffected.

claude-clouddev1 added 1 commit 2026-06-24 10:30:14 +01:00

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

ci / gate (pull_request) Successful in 2m8s

Details

ci / manifests (pull_request) Successful in 4s

Details

e1d7419a72

A push to a branch with an open PR fired both the `push` and `pull_request`
triggers, running the gate (and manifests) twice. On Gitea those runs are
byte-identical: unlike GitHub it has no merge-preview ref, so its
`pull_request` checks out `refs/pull/N/head` — the same commit a branch push
would. Scope `push` to `main` and let `pull_request` gate feature branches:
halves CI on every PR push, loses no coverage, and is forward-compatible — if
Gitea ever adds the merge ref, these runs upgrade to testing the merged result
for free.

oli merged commit 78272e2fd0 into main

2026-06-24 10:33:17 +01:00

oli deleted branch ci/dedupe-pr-runs

2026-06-24 10:33:17 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oli/rdbms-playground#44