Repository navigation
CI/merge hygiene: 'Workflows' check hangs pending; stacked-PR base deletion closes dependents #164
Description
Two related pain points surfaced while merging the 0.10.0 work (#157, #159/#160, #161, #162). Both forced manual intervention.
1. The Workflows (zizmor) check reports pending after its run succeeds
The workflows job in ci.yml (name: Workflows, runs zizmor) reliably shows as pending in gh pr checks and keeps the PR mergeStateStatus: BLOCKED even after its workflow run has concluded success (the job has conclusion=success and a completedAt, but the check status never reconciles). Observed on every PR in the 0.10.0 batch, each requiring an --admin merge.
Effect: no PR can auto-merge on green; the required check never reports green to branch protection.
Directions to investigate:
- The job runs on
pushwith noneeds/paths filter, so it may register a check context that branch protection tracks differently from the PR head SHA (duplicate/hung context). - Confirm whether the required-check name in branch protection matches exactly one context.
- Consider gating it behind the
changesfilter or giving it a stable check name, or moving the workflow-audit into thefmt/clippyfast job.
2. Deleting a base branch on merge closes stacked PRs instead of retargeting
Merging #157 with --delete-branch while #159 was stacked on feat/waf-response-phase closed #159 rather than retargeting it to main; it had to be reopened as a fresh PR (#160) after rebasing off the now-merged base. GitHub retargets dependent PRs only in some cases; a deleted base branch generally closes them.
Mitigations:
- Open stacked PRs against
mainfrom the start, or - Merge the base PR without
--delete-branchuntil the stacked PR is retargeted, then delete, or - Document the sequence in
CONTRIBUTING/release notes.
Neither is a correctness bug in the gateway; both are CI/release-process hygiene that cost time this cycle.
Activity
ndreno commentedon Sep 14, 2026
Root-caused. Two separate things were conflated under "the Workflows check hangs."
1. The spurious "Workflows" check (fixed in #167).
ci.ymltriggers onissue_comment(for/bench), and theworkflows(zizmor) job had no event guard, so every comment on a PR fired a CI run whose only active job was zizmor. Those comment-triggered runs are what produced confusing "Workflows" check runs. #167 addsif: github.event_name != 'issue_comment'to the job; now a comment runs nothing unless it is an authorized/bench.2. The actual merge-BLOCKED state (needs repo settings). Branch protection on
mainrequires onlyBuild,Unit Tests,Integration Tests, not "Workflows", withstrict: true(require branches up to date before merging). During the 0.10.0 merge train, each merge advancedmainand made the other open PRs out of date, which shows asBLOCKEDand forces a branch update plus a full CI re-run, or an admin merge. That is the friction that made me--adminmerge each PR, not the zizmor check.Recommendation for the maintainer (requires settings access):
stricton themainbranch protection, ormain, which updates and tests each PR against the queue head automatically so stacked/queued PRs stop invalidating each other.The stacked-PR base-branch-deletion pitfall from the original issue still stands as a process note: merge a base PR without
--delete-branchuntil the stacked PR is retargeted (or open stacked PRs againstmainfrom the start).ndreno commentedon Sep 14, 2026
Update:
strictis now off on themainbranch protection (required checks Build / Unit Tests / Integration Tests preserved). PRs will no longer be BLOCKED just for being behind main, which removes the merge-train friction and the need for admin merges. Combined with #167 (guarding the zizmor job from comment triggers), this resolves both halves of the issue. The stacked-PR base-deletion note remains as process guidance.ci: don't run the Workflows (zizmor) job on issue_comment events (#167)
ci: single "CI" gate job for branch protection (#169)