A team uses GitHub's merge queue to serialize merges and prevent conflicts on a high-traffic main branch. They want their agent-generated PRs to participate in the merge queue. Which configuration MOST appropriately integrates agent PRs with a merge queue?
Select an answer to reveal the explanation.
Short Explanation
Merge queues exist to stop parallel merges from breaking each other, so you shouldn't bypass them for agent PRs. You should put agent PRs through the same queue after checks and approvals pass, giving them the same serialization guarantees as human PRs. Separate queues still let races happen.
Full Explanation
GitHub's merge queue serializes merges to prevent the 'merge race' problem where two PRs pass CI independently but conflict when merged together. The value of the merge queue comes from all PRs going through a single serialized path. The configuration that bypasses the merge queue using admin permissions defeats the merge queue's purpose entirely. Agent PRs merging outside the queue can break main for human PRs currently in the queue, causing CI failures and additional back-and-forth. It also sets a bad precedent — a bypass for 'automated' changes that could introduce problems is exactly when you want serialization guarantees. The configuration that adds agent PRs to the merge queue after all required status checks pass and the minimum required approvals are satisfied is correct. Agent PRs should participate in the merge queue under the same conditions as human PRs: required status checks must pass, and minimum approvals must be satisfied, which for auto-merge candidates might be zero additional approvals if the agent review agent has already approved, or one approval from a human reviewer depending on policy. This treats agent-generated code with the same rigor as human code — appropriate since both affect the same main branch. The merge queue handles the serialization; the agent doesn't need to do anything special except ensure its PRs meet entry conditions. The configuration that creates a separate merge queue for agent PRs fails because two parallel queues can still create merge races between each other. The serialization guarantee only holds when all merges to main go through a single queue. The configuration that squashes all agent PRs into a single daily batch PR is a workaround, not an integration. Squashing multiple agent PRs into one large daily batch PR loses granularity, making it difficult to attribute problems to specific changes, increases the blast radius of any single issue, and makes rollback harder. It also creates a review burden: reviewers must evaluate the aggregate of many changes rather than individual, focused PRs.