Skip to content

[ci] Run PR checks on release branches - #441

Draft
Glitchy-Sheep wants to merge 1 commit into
release-0.32from
ci/run-checks-on-release-branches
Draft

[ci] Run PR checks on release branches#441
Glitchy-Sheep wants to merge 1 commit into
release-0.32from
ci/run-checks-on-release-branches

Conversation

@Glitchy-Sheep

@Glitchy-Sheep Glitchy-Sheep commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Problem

PRs into release branches get no CI. The only check they receive is DCO, an external GitHub App.

The trigger filter in .github/workflows/release.yaml matches the base branch of a PR:

  pull_request:
    branches:
      - "main"

A PR into release-0.32 has a base that is not main, so the workflow never starts. test, lint and pr-build are all skipped.

This matters because we ship from release branches. Tags are cut here, and the release job builds artifacts from those tags. Backports land by hand, which is the kind of change that most needs checks. Today a broken backport shows up only when the tag is built.

Fix

Add release-* to the filter.

The jobs need no changes. They already exist in this branch and match the ones on main:

  • same self-hosted runners, same ubuntu:22.04 container
  • same golangci-lint v2.11.4
  • the Taskfile targets they call are all present here: task test, task lint:check, task build:dist:all

Why this lands in the release branch

For pull_request events GitHub reads the workflow from the merge ref of the PR, not from the default branch. The same change on main would not affect PRs that target release-0.32.

Worth making on main as well, so future release branches are cut with the filter already correct.

Proof

This PR runs its own checks. GitHub built the merge ref from this branch, so the new filter already applied:

  • Test pass, 2m25s
  • Lint pass, 3m20s
  • Build for PR pass, 3m55s
  • release skipped, as its tag guard expects

Not in this PR

lint keeps continue-on-error: true, so it still cannot block a merge.

Three PRs merged into this branch while lint never ran (#407, #413, #414), so a backlog of violations was possible. The run above shows there is none. Dropping the flag is safe, but it belongs in its own PR.

Note for open PRs

Open PRs will not pick these checks up on their own. Merging into the base branch recomputes the merge ref but emits no new pull_request event. They need a push to the PR branch, or a close and reopen.

Signed-off-by: Roman Berezkin <roman.berezkin@flant.com>
@Glitchy-Sheep Glitchy-Sheep self-assigned this Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant