Code Quality never starts for some PRs — and an unrun workflow reads as a green PR

[rubenvdlinde]

On two repos the Code Quality workflow never started for a pull request, and the PR looked healthy while it happened.

gh pr checks reported four green entries — CodeQL, Analyze (actions), Analyze (javascript-typescript), Analyze (go) — and nothing red. That is indistinguishable at a glance from a passing PR, but the quality workflow (34–35 jobs: lint, build, PHPUnit matrix, gates) had not run at all.

Observed on:

• build(lint): migrate to eslint 10 + @nextcloud/eslint-config 9 doriath#235
• build(lint): migrate to eslint 10 + @nextcloud/eslint-config 9 pipelinq#828

both with head branch feat/eslint-10 and base development.

What did and did not work

• Opening the PR: no Code Quality run.
• Pushing an empty commit to re-fire pull_request: still no run.
• gh workflow run code-quality.yml --ref feat/eslint-10 (workflow_dispatch): ran fine — 34 and 35 jobs, zero failures. But a dispatched run does not attach to the PR, so the PR's checks stayed at four.
• Pushing a merge commit (after merging development in) finally produced a normal pull_request run.

Note on the branch-name filter

The push trigger is:

push:
  branches: [main, development, feature/**, bugfix/**, hotfix/**]

feat/** is not in that list — only feature/** — so a feat/… branch gets no push run either. doriath already has an open branch named ci/close-branch-trigger-gap, so this is partly known. Adding feat/** (and probably fix/**, chore/**, ci/**) would close the push half.

The pull_request half is the more serious one, because the base-branch filter ([main, master, development, beta]) does match and it still did not fire.

Why it matters

A workflow that never ran is indistinguishable from one that passed if you only read the PR's check list. Anything that merges on "no failures" will merge unmeasured code. Worth a guard that fails a PR carrying zero quality / check runs, rather than treating their absence as success.

[rubenvdlinde]

Measured: nothing in the required-checks set can detect this

Every one of the 17 core-app repos has branch protection on development requiring exactly one context:

required_status_checks.contexts = ["Conflict markers and PHP syntax"]
strict = false

That check comes from the lightweight lint workflow, which did run on the two affected PRs. None of the 34 quality / jobs is required, so a pull request whose Code Quality workflow never started satisfies branch protection and is mergeable — which is exactly how doriath#235 and pipelinq#828 presented: 4 green checks, 0 red, and no quality run at all.

So the hazard is not only "an unrun workflow reads as green to a human"; it also reads as green to the merge gate.

Recommended fix (branch-protection change — not applied, this is policy)

Add one always-present, currently-green quality / job to the required contexts on development. quality / Frontend Build and quality / REUSE compliance both run and pass on all 17 today; quality / Quality Report is unsuitable because it is red fleet-wide (it aggregates the gate failures).

gh api -X PATCH repos/ConductionNL/<app>/branches/development/protection/required_status_checks \
  -f 'contexts[]=Conflict markers and PHP syntax' \
  -f 'contexts[]=quality / Frontend Build'

Notes before rolling this out:

• A skipped job satisfies a required check in GitHub, so a job that legitimately skips on some PRs is safe to require; a job that never gets created is what blocks — which is the behaviour we want here.
• strict = false should stay as-is unless you also want branches forced up to date.
• nldesign has no frontend; pick REUSE compliance there if it is brought into scope.

I have deliberately not changed protection on any repo — it alters merge policy fleet-wide and belongs to whoever owns that policy.

Secondary, separate

The push trigger in each app's caller workflow lists feature/** but not feat/**, so a feat/… branch gets no push run either. That only affects the deduplicated push copy, not the PR run, so it is cosmetic next to the above.

[rubenvdlinde]

Measured the branch-filter half of this across all 18 apps on development today. It is in much better shape than when this was filed, with two specific gaps left.

merge-hygiene.yml: 18 / 18

The ** structural safety net is universal, so no branch is entirely without CI. That is the part that closes the "silent hole" the doriath comment describes.

push prefixes on code-quality.yml: one app short, one prefix short everywhere

prefix	apps covering it
feature/** fix/** bugfix/** hotfix/** chore/** refactor/** perf/**	18 / 18
feat/**	17 / 18 — openconnector is missing it
ci/**	0 / 18

Gap 1 — openconnector has no feat/**

Every other app added it. openconnector's list still reads feature/** only, which is the exact miss this issue opened on (feat/… branches running unchecked in openregister).

Gap 2 — ci/** is uncovered fleet-wide

This is not hypothetical: it is a prefix actively in use. Just from this weekend — ci/enable-playwright and ci/npm-jobs-on-node-24 in shillinq, ci/close-branch-trigger-gap in doriath, ci/enable-playwright-e2e in shillinq again. Every push to those got no Code Quality run.

Worth noting ci/** is the prefix most likely to carry workflow changes, so it is the one where an unrun pipeline is hardest to notice — the branch exists precisely because CI is being edited.

On whether to add prefixes at all

doriath's own comment in the file argues against, and I agree it is not the durable fix:

⚠️ Adding prefixes is not the durable fix; the next invented one is uncovered again. The durable fix is branch protection requiring a PR into development, which the pull_request trigger below already gates correctly.

That is right, and it means the priority order is: the pull_request half (the part this issue could not explain) matters, the push half is convenience. But ci/** is cheap to add and covers the branches where a missing run is least visible, so it seems worth doing even under that argument.

I have not swept this — it is 18 one-line edits and the argument above suggests it may not be wanted. Happy to if you want it.

Still unexplained

Nothing here addresses the serious half: pull_request matching its base-branch filter and still not firing on doriath#235 / pipelinq#828. I did not reproduce that today.