fix(gitops): make github structurally unable to accept a pull request #212

Merged

kblack0610 merged 1 commit from land/github-mirror-pr-guard into master

2026-09-01 19:37:36 +00:00

kblack0610 commented

2026-09-01 19:37:00 +00:00

Owner

Root cause of the recurring "merged but not deployed" problem, closed off at the source.

The mirror pushes refs/heads/* with --force --prune. So a PR merged on github is not merely undeployed - it is erased by the next push to forgejo master, silently. The mirror also replicates all 132 forgejo branches to github, which is what gives a stray gh pr create something to target.

Guards:

Guard	Status
Issues disabled on github	done via API (`has_issues=false`, verified)
PRs auto-closed on open	this workflow (github has no switch to disable PRs)
Reasoning + recovery documented	`docs/gitops.md` -> Canonical Remote

Already cleaned up alongside this: github #51/#52 closed as stale duplicates of forgejo #33/#37, and forgejo #141 closed (its branch was zero commits ahead). Both PR queues are now empty.

The workflow cannot be tested without opening a PR on the mirror, which is the thing it exists to prevent - so it is unverified until it first fires. YAML parses; pull_request_target + pull-requests: write is the standard shape for closing a PR from the base-repo context.

Root cause of the recurring "merged but not deployed" problem, closed off at the source. The mirror pushes `refs/heads/*` with `--force --prune`. So a PR merged on github is not merely undeployed - it is **erased** by the next push to forgejo master, silently. The mirror also replicates all 132 forgejo branches to github, which is what gives a stray `gh pr create` something to target. Guards: | Guard | Status | |---|---| | Issues disabled on github | done via API (`has_issues=false`, verified) | | PRs auto-closed on open | this workflow (github has no switch to disable PRs) | | Reasoning + recovery documented | `docs/gitops.md` -> Canonical Remote | Already cleaned up alongside this: github #51/#52 closed as stale duplicates of forgejo #33/#37, and forgejo #141 closed (its branch was zero commits ahead). Both PR queues are now empty. The workflow cannot be tested without opening a PR on the mirror, which is the thing it exists to prevent - so it is unverified until it first fires. YAML parses; `pull_request_target` + `pull-requests: write` is the standard shape for closing a PR from the base-repo context.

kblack0610 added 1 commit

2026-09-01 19:37:00 +00:00

fix(gitops): make github structurally unable to accept a pull request

checks / fleet-roster (pull_request) Successful in 5s

Details

checks / kustomize-builds (pull_request) Successful in 6s

Details

17d68e6198

The mirror is one-way and pushes with --force --prune, so a PR merged on
github never deploys AND is then erased by the next push to forgejo master.
Nothing surfaces an error. On 2026-08-28 eight PRs were opened there by
mistake; five survived only because an unrelated branch was later cut from
origin/master and dragged them back, and two were stale duplicates of
already-superseded forgejo PRs that would have reverted master if merged.

Issues are now disabled via the API. Github has no equivalent switch for
pull requests, so .github/workflows/reject-pull-requests.yml closes any PR
on open and points it at the canonical forge.

docs/gitops.md gets the reasoning and the recovery step for work already
stuck on github.