[eyelock]

Ferry · ynw build seat

Adds a merge queue to the develop and main rulesets and makes CI run in it, so each PR is tested on top of the ones ahead of it. Push runs on the default branches are no longer cancelled.

Changes

• infra/github/branches.tf: a merge_queue rule in both rulesets (develop squashes, main makes merge commits; ALLGREEN, up to 5 entries, 60 minute check timeout).
• .github/workflows/ci.yml: merge_group trigger; cancel-in-progress is now ${{ github.event_name == 'pull_request' }}.
• .github/workflows/protect-main.yml: merge_group trigger on main. The main ruleset requires "Verify PR source branch", and a merge_group run has no head_ref, so the job passes there (the source was already verified on the PR). Without this the queue into main would wait forever.
• Docs: .github/BRANCH_PROTECTION.md and infra/github/README.md.

ci.yml has no path filters or job if: conditions, so every job, and "All Clear", runs on merge_group. release.yml runs on tags and is not a required check.

Checks

terraform fmt -check clean, terraform validate valid, both workflow files parse as YAML. make check was not run: no Go code changed.

Human steps after merge

Applying changes the live rulesets, and merge this PR first (the required checks must already run on merge_group). Apply reads whatever is checked out, so update the shared checkout to the merged develop first:

git -C /Users/david/Storage/Workspace/eyelock/ynf switch develop
git -C /Users/david/Storage/Workspace/eyelock/ynf pull --ff-only
cd /Users/david/Storage/Workspace/eyelock/ynf/infra/github
export GITHUB_TOKEN="$(gh auth token)"   # repo and workflow scopes
AWS_PROFILE=ynf-terraform terraform init
AWS_PROFILE=ynf-terraform terraform plan
AWS_PROFILE=ynf-terraform terraform apply

Expected plan: exactly two updates in place, github_repository_ruleset.this["develop"] and github_repository_ruleset.this["main"], each adding a merge_queue block and nothing else (merge_method SQUASH on develop, MERGE on main). Anything else in the plan is drift: stop and do not apply. No tfvars are needed; the commands otherwise follow the Use section of infra/github/README.md.

After the apply, PRs merge with "Merge when ready", which adds them to the queue. The main into develop back-merge in each release goes in as a merge commit by an admin, around the queue (docs/how-to/cut-a-release.md).

Closes #188

[eyelock]

Hannett · ynw review seat

Verdict: ❌ changes needed — ynw-elw6 (waits on a decision), ynw-debp

Reviewed against ynw-6a32 (ynf #188) at 4a99e51.

The source-branch pass on merge_group. GitHub's merge-queue docs say: "Once a pull request has passed all required branch protection checks, a user with write access to the repository can add the pull request to the queue." main's ruleset requires "Verify PR source branch". So a PR from any other branch can't pass it, and can't be queued into main. The PR's head branch is fixed, and a PR retargeted to main never gets a pull_request run of protect-main (edited isn't in the default types), so the required check stays missing. I'm satisfied the guarantee holds. If you'd rather the queue run proved it by itself, the merge-group ref names the PR (gh-readonly-queue/main/pr-<n>-<sha>), so the job could look up that PR's head branch with pull-requests: read and apply the same test. That's optional.

Two things that aren't this PR's doing: repository admins can bypass the ruleset, and a PR's own branch can edit protect-main.yml. Both are true today, with or without a queue.

Other checks. ci.yml has no path filters, and nothing in it reads PR-only context, so every job and All Clear run on merge_group. The concurrency group is per ref, and cancel only on PRs is right. The merge_group branches filter is supported ("run only for merge groups that target specific branches").

What needs a change or a decision:

• ynw-elw6, the merge method. Both queues merge with MERGE. But repository.tf and BRANCH_PROTECTION.md say feature PRs into develop are squash-merged. A queue fixes one method per branch, and the gitflow back-merge into develop has to stay a true merge. Decision needed before merge: SQUASH on develop with back-merges taken around the queue, MERGE on develop for everything, or no queue on develop. It applies to every repository's merge-queue PR, so it's gone through the inbox.
• ynw-debp, the human steps. The commands match the README. But the apply runs in the shared checkout, so the steps should start by pulling the merged develop there. The expected plan could also be exact: two in-place updates, this["develop"] and this["main"], each adding only merge_queue, and anything else is drift to stop on.

Something I couldn't settle from GitHub's docs: whether a merge queue is available on a public repository owned by a personal account (eyelock is a user account). The docs pages I read don't say either way. That's in the same inbox item, as a check to make before applying.

CI's check job was still queued when I posted.

[eyelock]

Ferry · ynw worker seat

Addressed both review findings, in a07103c.

• ynw-elw6: merge_method is now per ruleset in local.rulesets (infra/github/branches.tf): develop SQUASH, main MERGE, per the recorded decision. repository.tf's comment already read "squash into develop"; .github/BRANCH_PROTECTION.md, infra/github/README.md and docs/how-to/cut-a-release.md now say develop squashes, main makes merge commits, and the once-per-release back-merge goes in as a merge commit by an admin around the queue. terraform fmt -check and validate pass.
• ynw-debp: the PR description's human steps now start with pulling the shared checkout to merged develop (--ff-only), and state the exact expected plan (two in-place updates, this["develop"] and this["main"], each only adding merge_queue; anything else is drift, stop).