Repository navigation
Let the reporter App merge its daily Activity PRs #275
Description
Part of #271 (Phase 3).
Why. Activity updates daily, and each day's PR should merge itself once the data check passes. main requires one approving review (branch protection, with required_approving_review_count: 1 and enforce_admins: false, checked 2026-09-29). As things stand, a person would have to merge a PR most days, which is how 14 drafts piled up before.
Work. Three settings on QuantEcon/website, and nothing else (checked 2026-09-29):
- The bypass. Add the App to
required_pull_request_reviews.bypass_pull_request_allowances.apps. The API takes the slug,quantecon-news-reporter.mainuses classic branch protection and has no rulesets. - The gate. Make Build Preview's
buildcheck, which runs the data check, a required status check onmain. Leave "require branches to be up to date" off, so daily PRs don't need rebasing. No check is required today, so without this a PR that bypasses review could merge with the check red or still running. - Auto-merge. Turn on "Allow auto-merge" in the repository settings, so the App can enable auto-merge on its PR. It's off today. Without it, the reporter's workflow has to wait for the check itself before merging.
The App is quantecon-news-reporter, App ID 4063768. The rename proposed in QuantEcon/reports-activity#91 keeps the App ID, but changes the slug the classic API names it by, so re-check the bypass list after the rename.
Acceptance criteria
-
buildis a required status check onmain, and "Allow auto-merge" is on. - The App is the only entry in the approval rule's bypass allowances. Repository admins can still merge without approval while
enforce_adminsis off. - A test PR from the App merges with the data check green and no approval.
- A test PR from the App whose data check fails does not merge.
- A PR from anyone else who isn't a repository admin still needs one approval.
- After the rename in QuantEcon/reports-activity#91,
gh api repos/QuantEcon/website/branches/main/protectionstill lists the App under the bypass allowances.
Activity
mmcky commentedon Sep 29, 2026
Settings in place on 2026-09-29, read back through the API:
mainbuild, from GitHub Actions. Branches don't need to be up to datequantecon-news-reporteronlyenforce_adminsis off, so admins can still mergeOne change to the plan: merge directly, and don't rely on auto-merge. GitHub's docs describe the bypass only as letting the App "push code to the branch without creating pull requests", and they don't say whether auto-merge honours it. A July 2026 report in community discussion #136531 says the auto-merge path ignores bypass actors, while the REST merge endpoint honours them.
So the reporter's workflow should wait for the required check and then merge with the App's token:
gh pr checks <n> --required --watch --fail-fastgh pr merge <n> --squashIf the check fails, the PR stays open. Auto-merge stays on, since it costs nothing, and the first test shows whether the reporter can use it.
Still to test, with the first run of the new workflow in QuantEcon/reports-activity#91:
buildgreen and no approval;buildfails does not merge. One deliberately failing PR (a data file the check rejects), closed afterwards, covers this.The non-admin criterion is ticked from the rule itself: it requires one approval, and the App is its only bypass actor.
mmcky commentedon Sep 29, 2026
Correction to the merge steps in my comment above.
gh pr mergewon't work here. It uses GitHub's GraphQL merge, which refuses a PR whose base is still blocked (here, by the approval rule) before the App's bypass is ever tried. The community report about bypass actors covers the REST merge endpoint.The reporter's workflow should:
buildcheck run exists on the PR's head commit and has succeeded. Read it with the workflow's ownGITHUB_TOKEN(the website is public), because the App has no checks permission. Don't rely ongh pr checks --required --watch: it can exit beforebuildhas registered.gh api -X PUT repos/QuantEcon/website/pulls/<n>/merge -f merge_method=squash -f sha=<head sha>. Passing the SHA means a newer, unchecked commit can't be merged.The failing-PR test (criterion 4) has to be a mode in the workflow itself, for example a manual-dispatch input that writes a data file the check rejects, because the App's private key exists only as an Actions secret. That run should confirm GitHub refuses the merge, then close the PR and delete its branch.
mmcky commentedon Sep 29, 2026
The failing-PR criterion is proven by the Activity feed's self-test, run 36640069153 (2026-09-29). The App opened #288, adding only
_data/activity/2000-01-01-software.yml, an empty list:build, the guard step "Limit reporter PRs to Activity data" passed ("1 added, 0 appended to"), and the data check failed: "must be a non-empty list of entries".mainwas untouched.The bypass list after the rename. The App is now QuantEcon Activity Feed (
quantecon-activity-feed), App ID 4063768. Re-checked in the repository settings on 2026-09-30,main's branch protection still lists it as the approval rule's bypass actor ("quantecon-activity-feed / QuantEcon Activity Feed"), and the repository still has no rulesets.build's guard keys on the bot user ID (294005175), which the rename didn't change.Still to prove: a green PR merges without approval. GitHub's refusal named the approval rule as well as the failing check, so it doesn't show that the bypass lets a green PR through. The first merge-mode PR from QuantEcon/reports-activity#91 is that test. It fails safe either way: if the bypass doesn't hold, the PR stays open and the alert fires.
Criteria 4 and 6 are ticked; criterion 3 waits for that PR.
mmcky commentedon Sep 30, 2026
Status (2026-10-01). Lecture entries went live on 2026-09-30 in PR mode. The maintainer set
ACTIVITY_FEED_MODEtoprso the first summaries are read before they're published, and merged the first lecture PR, #293, by hand. A hand merge doesn't test the bypass, so criterion 3 still waits for the first PR that merges itself once the mode is back tomerge. The bypass entry and the requiredbuildcheck were last confirmed on 2026-09-30, in the comment above.