[eyelock]

Weller · ynw worker seat

Adds a merge queue to develop and main, so two PRs that are each green cannot combine red (the assistants #160 / assistants #176 failure).

Changes

• infra/github/branches.tf: a merge_queue rule on both rulesets. develop squashes, main makes a merge commit, matching the repository's merge settings. ALLGREEN grouping, up to 5 entries per build and merge, 5 minute wait, 60 minute check timeout.
• .github/workflows/ci.yml: merge_group trigger. There is no pull request to diff in the queue, so the paths filter step is skipped and every filter output is true: all jobs run, none is skipped, and All Clear cannot stall the queue waiting on a skipped check.
• .github/workflows/protect-main.yml: merge_group trigger. A merge group has no head_ref, so the job passes there (the PR already passed it to enter the queue).
• .github/BRANCH_PROTECTION.md: describes the queue.

The only required checks are All Clear and Verify PR source branch, so those two workflows are the only ones that needed the trigger. Skill Security stays inside All Clear.

Checked

terraform fmt and terraform validate (backend off) pass; terraform apply was not run. make check passed.

Next action after merge (not applied by this PR)

A maintainer applies the ruleset change. First update the shared checkout /Users/david/Storage/Workspace/eyelock/ynh to the merged develop, then:

cd /Users/david/Storage/Workspace/eyelock/ynh/infra/github
export AWS_PROFILE=ynh-terraform
export GITHUB_TOKEN="$(gh auth token)"
terraform init
terraform plan
terraform apply

terraform plan must show exactly two in-place updates, github_repository_ruleset.this["develop"] and github_repository_ruleset.this["main"], each adding only merge_queue. Stop on anything else: that is drift, and applying would change it. Until it is applied the queue does not exist; the workflow triggers are harmless before then. Done when a PR merges through the queue and All Clear runs on the merge_group ref.

Note: protect-main.yml's merge_group trigger has no branches: [main], so it also runs (and passes) on develop's queue. That is harmless.

Not verified before merge: the Skill Security action's behaviour on a merge_group event; it is only observable in the first queued run.

Closes #794

[eyelock]

Hannett · ynw review seat

Verdict: ❌ changes needed — ynw-vjh1, ynw-1i9c

Reviewed against ynw-jj0g (ynh #794) at bc4e466, and against the merge-method decision now made: develop's queue squashes, main's makes merge commits, and the back-merge from main goes in once per release as a merge commit, by an admin, around the queue.

The settings are sound.

• ALLGREEN means every entry must pass on its own.
• 5 per build and per merge is plenty at ynh's pace.
• With min_entries_to_merge = 1, the 5-minute wait hardly applies.
• 60 minutes is far above ynh's longest job: Test takes about 82 seconds on develop's last green run.
• merge_method per ruleset matches the decision.

The queue's CI.

• Forcing every filter output true on merge_group is right. true || … makes the string "true", and on a PR false || steps.filter.outputs.x still yields the filter's own value, so PR behaviour is unchanged.
• Every job then runs. Packaging Config has passed before (run 42319979756), so I don't expect a stall.
• Skill Security: the pinned action diffs against the base only when changed-only is set and the event is pull_request. On merge_group it scans everything, so it shouldn't stall. The first queued run will confirm it, as you say.

The source-branch pass on merge_group. Same reading as ynf #189, ynm #126 and ynr #116. GitHub adds a PR to the queue only once it "has passed all required branch protection checks", and "Verify PR source branch" is one of main's. So no other branch can reach main through the queue.

What needs a change:

• ynw-vjh1. The release steps still forbid what the decision now requires. .claude/rules/branching.md, .claude/commands/release.md and .claude/agents/ynh-releaser.md say "Never --admin", and true-merge the back-merge through its PR. Through develop's queue that PR would be squashed. The admin back-merge needs writing in as the one sanctioned exception, done by a human. BRANCH_PROTECTION.md's merge-method lines and the infra README need the same change.
• ynw-1i9c. The human step is terraform apply on its own. It should be the README's sequence: update the shared checkout first, export the env, init, then a plan that must show exactly two in-place updates adding merge_queue, then apply. A small one for consistency: protect-main's merge_group has no branches: [main] filter.

Not settled from GitHub's docs: whether a user-owned public repository can have a merge queue. That check is in the inbox item.

[eyelock]

Weller · ynw worker seat

Both review fixes are pushed in 1e92451 (ynw-vjh1) and the PR body (ynw-1i9c).

ynw-vjh1: the back-merge into develop is now written as the one sanctioned --admin merge, as a merge commit, by a human, around the queue and only after its CI is green. Changed: .claude/rules/branching.md (back-merge bullet, feature PRs now join the queue, the --admin rule with its single exception), .claude/commands/release.md (release PR goes through main's queue; back-merge step with the admin command), .claude/agents/ynh-releaser.md (steps 3 and 5; the releaser never merges it), .github/BRANCH_PROTECTION.md and infra/github/README.md (method per branch; back-merge goes around the queue).

ynw-1i9c: the PR body's human step is now the full sequence (update the shared checkout to merged develop, export AWS_PROFILE and GITHUB_TOKEN, terraform init, terraform plan expecting exactly two in-place updates to the develop and main rulesets each adding only merge_queue, stop on drift, then terraform apply), plus the note that protect-main.yml's merge_group also runs on develop's queue.