check-branch can never pass: policy requires 'beta' or 'hotfix/*' but petstore has no beta/development branch

[rubenvdlinde]

Symptom

check / check-branch fails on any ordinary pull request into main:

::error::Pull requests to main must come from 'beta' or a 'hotfix/*' branch.
Your branch 'fix/phpmd-ignore-namespaces' does not match any allowed pattern.

Observed on #8 — https://github.com/ConductionNL/petstore/actions/runs/30797406688/job/91634009106

Cause

.github/workflows/branch-protection.yml calls the shared
ConductionNL/.github/.github/workflows/branch-protection.yml@main, which
enforces the fleet's development → beta → main promotion flow.

petstore has neither a beta nor a development branch. git ls-remote --heads origin returns only main plus feature branches, and the repo's
default branch is main.

So the policy permits exactly two sources into main — beta (does not exist)
and hotfix/*. No ordinary contribution branch can ever satisfy it. The
only way to land a normal change today is to mislabel it as a hotfix/*, which
defeats the point of the check and pollutes the branch vocabulary.

This is a pre-existing repo/policy mismatch, not caused by any one PR — it will
block every future PR into main the same way.

Options

1. Create the missing branches (development, beta) and adopt the fleet
   promotion flow, so the shared policy is satisfiable as written. Consistent
   with the rest of the fleet.
2. Opt petstore out of the shared branch-protection workflow, or pass it a
   configuration that reflects a single-branch repo, if petstore is
   deliberately main-only (it is a demo/reference app).

Option 2 is probably right if petstore is intentionally main-only; option 1 if
it should behave like the other apps. This needs a decision rather than a patch.

Blocked on this

#8 (fix(quality): phpmd DevelopmentCodeFragment could never fire on namespaced code) cannot go green while this stands. That PR's own change is measured
neutral — 0 new phpmd findings — but check-branch fails independently.

[rubenvdlinde]

Fixed — but it was two independent faults, not one

Fault A — the missing branches (this issue)

Confirmed: 40 branches (not 30), neither beta nor development. The shared ConductionNL/.github/.github/workflows/branch-protection.yml@main job check-branch enforces target main → source must be beta or ^hotfix, so no ordinary branch could ever satisfy it.

Fix chosen: create the missing branches. All 13 other Conduction repos sampled (openregister, opencatalogi, openconnector, docudesk, nldesign, scholiq, openbuild, pipelinq, decidesk, doriath, larpingapp, softwarecatalog, nextcloud-app-template) have both, regardless of whether their default is main or development. petstore was the sole fleet outlier.

Option 2 from this issue — relaxing check-branch — was rejected on evidence: the shared workflow's trigger is bare on: workflow_call: with no inputs: block at all, so a repo cannot declare its own allowed source branches without editing the shared workflow, i.e. a fleet-wide change to accommodate one outlier. It would also leave petstore's sync-to-beta.yml (on: push: branches:[development]) and release-beta.yml (on: push: branches:[beta]) as dead code.

• development created at 0a9c2e2 (main tip); beta then created by the repo's own sync-to-beta.yml.
• ci(release): set beta release app-name to petstore #21 fixed release-beta.yml's app-name: app-template scaffold leftover (merged).

Fault B — the required check was never reported at all

gh api repos/ConductionNL/petstore/branches/main/protection → 404. Protection is via org rulesets, and ruleset 14128365 requires the context branch-protection / check-branch. petstore's caller job is named check:, so it reports as check / check-branch — a context nothing requires.

The required context was therefore permanently pending, and merges landed via the OrganizationAdmin bypass. Fault A made ordinary PRs fail; Fault B made the failure invisible.

⚠️ Order matters: fixing only Fault B makes things stricter, turning an invisible failure into a hard block for every non-hotfix/* PR. Fault A had to be fixed first or together.

• ci: rename branch-protection caller job id to branch-protection #20 fixes the job id on main — blocked solely on 2 approving reviews; both required contexts pass.
• ci: rename branch-protection caller job id so the required check reports #23 lands the same fix on development, because development/beta were branched from main before ci: rename branch-protection caller job id to branch-protection #20 and would otherwise keep reporting under the wrong context.

Proof

PR #22 (development → beta) — an ordinary, non-admin PR. Exactly one check-branch job:

name:       "check / check-branch"
conclusion: "SUCCESS"

job log: PR: development → beta / ✓ Branch check passed: development → beta

⚠️ beta → main remains UNVERIFIED. beta is byte-identical to main (compare/main...beta → status: "identical", ahead_by: 0, behind_by: 0), so GitHub refuses to open the PR: "No commits between main and beta". Making beta diverge requires merging #22, which is the development→beta human gate — not something to cross automatically. The branch-policy logic for that arm is a pure string comparison in the same script already proven green, and #20 (hotfix/* → main) reports branch-protection / check-branch: SUCCESS, so both target arms are exercised — but the specific beta → main cell has not been observed and I am not claiming it.

Still open, not fixed here

• Bot-authored PRs land in action_required — the auto-created release PR's checks never start on their own.
• Four more app-template scaffold leftovers: release-stable.yml, openspec-sync.yml, issue-triage.yml (app-name: app-template) and documentation.yml (cname: app-template.conduction.nl). release-stable.yml is the same latent bug as ci(release): set beta release app-name to petstore #21 and will misfire on the first stable release.
• Same detached-context defect elsewhere in the fleet: docudesk (job check:) and larpingapp (job protect:).