PRs targeting release/** get no pull_request CI, so a release PR is never tested against its merge result

[BitHighlander]

The gap

.github/workflows/ci.yml:

on:
  push:
    branches: [master, develop, 'feature/**', 'fix/**', 'release/**', 'hotfix/**']
  pull_request:
    branches: [master, develop]

pull_request fires only for PRs whose base is master or develop. A PR targeting release/** therefore produces no pull_request run at all. Its check rollup is populated entirely by the push run on the head branch.

Empirically: of the last 100 workflow runs repo-wide, 35 are event=pull_request and every one has base.ref == develop. Zero with a release/** base.

Why it matters

Every job pins ref: ${{ github.event.pull_request.head.sha || github.sha }} (11 checkout steps). So for a release-targeting PR, CI tests the head commit in isolation — never the base, never the merge result.

Concretely, on PR #443:

• Checks came from run 32018516938, event=push, headSha=ee15eded1, on branch fix/rng-build-guards.
• git merge-base ee15eded1 release/7.14.2 = 440619703 — the base as of the rebase. Two commits (885b485c4, 7e07b2d92) had landed since, and no job saw them.
• The run's own conclusion was cancelled, not success — nine jobs succeeded, python-integration-tests was killed at the 30-minute timeout. A per-job reading says "eight green"; the run says cancelled.

So for release PRs, "the PR is green" is not a statement about what will be on the branch after merge. There is no merge queue (gh api repos/.../rulesets → []) and release/7.14.2 is not protected (branch-protection API → 404), so nothing else closes the gap.

What does work

push on release/** is in the trigger list, so the branch is tested after merge. The validation exists — it just arrives after the decision instead of before it.

Suggested fix

Add 'release/**' (and 'hotfix/**') to the pull_request branch list so release PRs get a merge-result run before merge, rather than a head-only run. Given this repo cuts security releases on release/** branches, that is where pre-merge validation matters most.

Found while merging #443 into release/7.14.2.

[BitHighlander]

Related gap in the same trigger block, found while merging #478: the push list is

branches: [master, develop, 'feature/**', 'fix/**', 'release/**', 'hotfix/**']

so a docs/** branch gets no CI at all — gh pr checks reports "no checks reported" and mergeStateStatus is CLEAN, i.e. it looks more mergeable than a branch that ran and failed.

Harmless for a genuinely docs-only change, but the protection is the branch name, not the content: put a .c file on a docs/** branch and it merges unvalidated with a clean-looking PR.

Worth fixing alongside the pull_request base list: either add the missing prefixes, or drop the branch filter on pull_request entirely so every PR is tested regardless of where it came from.