The two required-context shims disagree on base: a non-Dev_new_gui PR can never receive smoke-test #16200

The gap

The two required-context shims disagree about which PRs they cover:

# .github/workflows/docker-smoke-required-context.yml
on:
  pull_request:
    branches: [ Dev_new_gui ]

# .github/workflows/python-required-context.yml
on:
  pull_request:

docker-smoke-required-context.yml is base-filtered; python-required-context.yml is not. A pull request whose base is anything other than Dev_new_gui therefore gets python-required-context and no smoke-test context at all.

smoke-test is a required status context. A PR that can never receive it is blocked with no failing check to fix — absence, which is the one state that cannot be waited out or re-run.

Why it is latent, and exactly when it stops being

Nothing exercises it today because main is closed to pull requests by policy and every PR targets Dev_new_gui. The day someone opens a release PR into main, or any branch-to-branch PR, it stops being latent — and the symptom will be an absent required context, which is the hardest CI state to attribute. Two sessions spent a combined afternoon on an unrelated instance of absence before establishing what it was not.

The shim pattern exists so a required context is always published, including when the real job legitimately does not run — docker-smoke-required-context.yml's own header says so:

docker paths untouched -> smoke-test below, which reports the context green

A base filter is a second, undocumented condition on that guarantee, and it is present in one shim and not its sibling.

Not the cause of #16171

Recording this because it was found while investigating #16171's absent smoke-test, and it is not the explanation there — that PR's base is Dev_new_gui, so the filter is satisfied. The mechanism in that case is still unknown; the exclusion list across two sessions covers the workflow file, the branch tree, branch/base divergence, the event, the base filter, the conflict state, the approval path, rulesets, Actions policy, and the author. What survives is that it is intermittent across dependabot PRs from the same generator — #15977 and #16171 hit it, #15976/#15978/#15979/#15980 did not.

Acceptance criteria

• Both required-context shims cover the same set of pull requests — either both carry the base filter or neither does, decided deliberately and with the reason recorded in the file
• If the filter is kept, the workflow header states that the context is not published for other bases, so the guarantee it documents matches what it delivers
• A test asserts every shim publishing a required context has the same trigger conditions as its siblings, so the next shim cannot drift from the set silently
• The test enumerates shims by discovery rather than by a hand-written list, and binds a floor to what it examined

Related

• chore(deps): bump the npm_and_yarn group across 6 directories with 7 updates #16171 — where this was found; not its cause
• ci(perf): restore deleted path filters via the required-context shim pattern #15363 — restoring deleted path filters via the shim pattern
• ci: the frontend required-context shim is created AFTER the real suite, so a red frontend suite may be masked #14922 — the frontend shim created after the real suite
• security(ci): the required-context shim trusts a path filter the pull request itself can rewrite #14408 — a shim trusting a path filter the PR can influence