`branches: [release/1.0, master]` meant a stacked pull request never matched.
Gitea does not stay silent about a workflow it sits out: it posts the required
context itself with state `skipped`, the combined-status rollup reports that as
`success`, and the merge gate accepts it. Retargeting does not repair it - the
skip is a commit status on the head sha, so it survives the base change.
Measured on Gitea 1.27.3 with throwaway PR #94: one status on the head sha,
`skipped`, rollup `success`, and POST .../merge cleared branch protection
(409 `head out of date`, from a deliberately wrong head_commit_id in the probe)
where the control - a required context with no status at all - was refused
(405 `Not all required status checks successful`).
Fixing this at the gate is not possible: Gitea branch protection can require
that a context is PRESENT, never that it is SUCCESS. Its entire status-check
vocabulary is `enable_status_check` and `status_check_contexts`, per this
server's own /swagger.v1.json. So the fix has to be upstream - never emit a
skip - which means no event filter.
Cost: every pull request now runs the full ~8 minute suite, including
intermediate steps of a stack. Also corrects CI-01's header, which recorded the
failure mode as fail-closed (pending forever) when it is in fact fail-open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
adminandClaude Opus 5
0308940243