Skip to content

ci: auto-close PRs opened from a fork's default branch#477

Merged
bdraco merged 1 commit into
sblibs:masterfrom
bdraco:chore/auto-close-prs-from-master
Apr 23, 2026
Merged

ci: auto-close PRs opened from a fork's default branch#477
bdraco merged 1 commit into
sblibs:masterfrom
bdraco:chore/auto-close-prs-from-master

Conversation

@bdraco
Copy link
Copy Markdown
Member

@bdraco bdraco commented Apr 23, 2026

Summary

Adds a GitHub Actions workflow that auto-closes pull requests opened from a fork's default branch (the PR's head branch shares the upstream default-branch name) and posts a friendly comment explaining the problem and how to move the work to a feature branch.

We've seen this come up several times recently (see e.g. #456, #430). When a contributor PRs from their fork's `master`:

  • Their fork's `master` permanently diverges from `sblibs/pySwitchbot:master`, making it hard to keep the fork in sync.
  • Any additional commits pushed to `master` on the fork get tacked onto the open PR, so the contributor can't work on multiple changes in parallel.
  • Pushing maintainer fixes to the PR is awkward, since it means committing directly to the contributor's default branch.
  • Local checkouts get ambiguous `master` names between upstream and the fork.

How it works

  • Triggers on `pull_request_target` (`opened`, `reopened`) — runs in the base-repo context so it has write permissions, but does not check out PR code, so no untrusted code executes.
  • Fires only when the PR head is in a fork (`head.repo.full_name != base.repo.full_name`) and `head.ref == repository.default_branch`. Internal branches and PRs from feature branches are untouched, even if a feature branch happens to be named `master`.
  • Uses `actions/github-script` pinned to a full SHA (security best practice for `pull_request_target`).

Pattern adopted from esphome/esphome#15957.

Test plan

  • Workflow lints (`actionlint` if available; otherwise GitHub's built-in YAML validation on push).
  • After merge, open a test PR from a fork's default branch and confirm:
    • The friendly comment is posted.
    • The PR is closed.
    • PRs from feature branches are not affected.

When a contributor opens a PR from their fork's default branch (a
branch with the same name as upstream's default), it permanently
diverges their fork from upstream and makes the PR awkward to iterate
on:

- Their fork's default branch can no longer fast-forward from upstream
  without losing the PR state, so syncing the fork breaks.
- Any additional commits pushed to that branch on the fork get tacked
  onto the open PR, so the contributor can't work on multiple changes
  at once.
- Maintainer pushes to the PR end up landing on the contributor's
  default branch, which is bad form even when GitHub allows it.
- Local collaboration is awkward: in a checkout, the default branch
  name becomes ambiguous between upstream and the fork.

This workflow auto-closes such PRs with a friendly comment that
explains the issue and walks the contributor through resyncing their
fork's default branch and re-opening from a feature branch.

Pattern adopted from esphome/esphome#15957.

- Triggers on `pull_request_target` (opened, reopened) so the workflow
  has write permission for forks but does not check out PR code.
- Fires only when the PR head is in a fork AND `head.ref ==
  repository.default_branch` — internal branches and PRs from
  feature branches are untouched.
- `actions/github-script` pinned to a SHA per security best practice
  for `pull_request_target` workflows.
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 23, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@bdraco bdraco merged commit c4227f9 into sblibs:master Apr 23, 2026
6 checks passed
@bdraco bdraco deleted the chore/auto-close-prs-from-master branch April 23, 2026 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant