Release branches have no CI and no branch protection, and no checks are required anywhere #54

Summary

Branches other than the default branch have no ruleset coverage and no CI, and separately, no status checks are required on any branch. This was found while delivering #53, which targeted release/v1.0.0. Four problems compound: the first two are verification gaps, and the last two are breaches of requirements the MSXOrg ways-of-working canon already states — not local preferences to be debated.

1. No CI runs on pull requests against release branches

.github/workflows/Process-PSModule.yml only listens to pull_request events whose base branch is main:

on:
  pull_request:
    branches:
      - main

A pull request based on release/** therefore gets no checks at all, and gh pr checks reports "no checks reported on the branch".

2. A green workflow_dispatch run is not equivalent to a green pull-request run

The workaround for problem 1 is dispatching the workflow manually against the branch. That is weaker than it looks, because some jobs are gated on the event type.

Verified on #53:

Lint-Repository is the super-linter job that runs markdownlint, textlint and codespell. In a pull request that added three new markdown pages and reworked the README, the entire prose-linting surface silently did not run. The change happened to be clean — it was pre-checked locally against .github/linters/ and the post-merge run confirmed it — but nothing in the dispatch result said "prose was never linted".

Anyone using dispatch as a stand-in for pull-request CI needs to know which jobs it does not exercise. Ideally dispatch would not silently skip verification jobs at all.

3. Release branches have no branch protection whatsoever

This is the serious one. The repository has a single ruleset, GitHub Flow (id 19735208), whose condition is:

{ "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } }

~DEFAULT_BRANCH resolves to main, so the ruleset does not apply to anything else. Confirmed directly against the API:

$ gh api /repos/PSModule/Yaml/rules/branches/main
deletion
required_linear_history
pull_request
non_fast_forward

$ gh api /repos/PSModule/Yaml/rules/branches/release%2Fv1.0.0
(empty — no rules apply)

There is also no classic branch protection on either branch (/branches/*/protection returns 404 for both). So on release/**, all of the following are currently permitted:

• Pushing directly, with no pull request at all — the pull_request rule is what requires one, and it is scoped to main.
• Force-pushing — non_fast_forward is not enforced.
• Deleting the branch — deletion is not enforced.
• Non-linear history, and any merge method, not just squash.

And for pull requests that do target a release branch, none of require_code_owner_review, required_review_thread_resolution, require_last_push_approval or dismiss_stale_reviews_on_push apply. #53 reported mergeStateStatus: CLEAN and was mergeable by anyone with write access, unreviewed, with zero checks.

A release branch is the branch a version actually ships from. It currently has strictly weaker protection than any feature branch merging into main.

This violates two canonical release-management requirements

The gap is not just a local misconfiguration — the release-management capability spec states requirements that this configuration cannot satisfy:

A release per merge. One merged PR to a release branch is one release, and the PR review gate is the release gate.

There is no PR review gate on release branches here, so the release gate the spec relies on does not exist.

Only artifact-affecting changes release. A change that does not flow into the artifact (documentation, CI config) MUST NOT produce a release — though validation still runs on every merge.

Validation does not run on release-branch pull requests at all, and the matching success criterion — "a documentation-only merge produces no new version but still runs its CI checks" — is not met. #53 was exactly that case: a documentation-only merge into a release branch, with no CI.

So problems 1 and 3 are two halves of one documented requirement that the repository configuration does not currently meet.

4. No status checks are required anywhere, so auto-merge does not wait for CI

The ruleset contains no required_status_checks rule at all — not for release branches, and not for main either. The gate on main is code-owner review (CODEOWNERS assigns * @PSModule/module-maintainers), with a reviewer expected to notice red checks.

The consequence is easy to miss: GitHub's auto-merge only waits for checks it has been told are required. With no required status checks configured, an armed auto-merge fires as soon as the review conditions are satisfied, regardless of whether CI has finished or passed. "Auto-merge is armed" reads as "this will wait for CI"; on this repository it does not.

The review rules do provide real cover — require_last_push_approval and dismiss_stale_reviews_on_push mean a later push drops the approval rather than slipping through it — so this is not currently being exploited. #47 is armed as of writing with all 66 checks complete and green on 6ec4321, which is safe. But the safety comes from the timing of the approval, not from any rule that says CI must pass.

This is a conformance gap, not an open decision

Requiring status checks has already been decided. Branching and Merging is normative on the point:

A branch ruleset on the protected branch defines the merge requirements every pull request must satisfy before it can land — the required status checks, the required approvals, and any others the ruleset enforces ... The ruleset is configured on the repository (in its settings), not in these files; this section defines what it must enforce.

It then describes auto-merge as squash-merging "the moment every one of those requirements is satisfied — and not before". With no required status checks declared, that "and not before" guarantee does not hold, because there is nothing for auto-merge to wait on beyond approval.

So this repository is in breach of the branching canon, and problem 3 is a second breach of the same document's protected-branch model. The question is not whether CI should be binding — canon already says it must be. The only genuinely open part is operational: which check contexts to name.

This makes required status checks the higher-value half of the fix rather than a footnote to the trigger change. Fixing problem 1 alone makes checks visible on release-branch pull requests; it does not make them binding anywhere.

Proposed changes

Four independent fixes. Items 3 and 4 are the ones that matter most, and both are conformance repairs rather than new policy: 3 closes the governance hole, and 4 is what makes CI actually binding rather than merely visible.

1. Extend the workflow trigger so release branches get pull-request CI:

   on:
     pull_request:
       branches:
         - main
         - 'release/**'

   Confirm against PSModule/Process-PSModule that the reusable workflow keeps Publish-Site and Publish-Module skipped for non-main bases. They were correctly skipped in run 30756441401, so this looks safe, but it should be verified rather than inferred from one run. If the guard is not upstream, that part belongs in PSModule/Process-PSModule instead.

2. Make workflow_dispatch runs honest. Either stop gating verification jobs such as Lint-Repository on the event type, or have the workflow summary state plainly which jobs were skipped because the run was not a pull request. Silent skipping is what makes dispatch misleading as a substitute.

3. Extend ruleset coverage to release branches. Add refs/heads/release/** to the GitHub Flow ruleset's ref_name.include, so release branches inherit the pull-request requirement, code-owner review, thread resolution, squash-only merges, linear history, and force-push and deletion protection.

4. Add a required_status_checks rule covering both main and release/**, so CI is binding rather than advisory and auto-merge genuinely waits for it. This is not an open design question — Branching and Merging already requires the ruleset to enforce required status checks, so adding the rule brings the repository back into conformance rather than introducing a new policy. The open part is purely operational: which check contexts to name, given that the reusable workflow's job names can change between Process-PSModule versions. Prefer contexts that are stable across upgrades over pinning every matrix leg.

This is likely an organisation-wide pattern rather than a PSModule/Yaml quirk — any PSModule repository that uses a release branch has the same exposure, and the missing required-checks rule affects every repository using this ruleset regardless of whether it has a release branch. If the ruleset is templated from PSModule/.github, the fix belongs there and this issue should route accordingly.

Acceptance criteria

• A pull request based on a release/** branch reports the same checks as one based on main.
• Publish-Site and Publish-Module remain skipped for non-main bases.
• Release branches require a pull request, code-owner review, and resolved review threads, and reject force-pushes and deletion.
• The release-management spec's "the PR review gate is the release gate" and "validation still runs on every merge" hold for release branches in practice, not just on paper.
• A required_status_checks rule exists for both main and release/**, satisfying Branching and Merging, and an armed auto-merge does not land a change whose checks have not finished.
• A workflow_dispatch run either exercises the same verification jobs as a pull-request run, or reports which ones it skipped.
• No behaviour change for pull requests targeting main.

Out of scope

• The release process itself.
• Any content change in 🌟 [Major]: New PowerShell module v1.0.0 with complete YAML 1.2.2 command suite #47 or 📖 [Docs]: YAML commands grouped by task with in-depth guides for each area #53.