Skip to main content

/kosuke:batch-merge

/kosuke:batch-merge merges a batch of pull requests into one pull request. Kosuke runs it in a batch session when the project has Batch merging on. Each pull request in it is approved on GitHub by someone other than its author, or has its member's go-ahead, on its latest commit, and its own QA passed or left only blocked items. The batch agent judges each blocked item: it goes on and lists the item as not tested on the batch pull request, repairs what the sandbox can fix, or leaves the pull request out when the blocked item is the change itself. It checks that they work together, then leaves one pull request for you to merge. When you merge it, every task in the batch is completed with that merge.

When it runs​

Kosuke starts the first batch session on a go-ahead when the project has Batch merging on and no run of its merge agent is open. At most two batches are open per project, with one built on the other. The batch agent, not Kosuke, decides whether a batch is worth running now and which pull requests go in, and names the batch. You do not run this skill yourself. The batch agent acts as the workspace, not as a member: as Kosuke, an admin of the workspace. It reads every project's sessions and their QA Reports, and writes only in its own project.

A go-ahead on the pull request's latest commit is what puts it in: Sensei gives it as you, after you approve its card, or by your Merge rule. See The go-ahead.

The batch merges into the project's Target Branch, or the default branch when none is set. The repository's settings decide how the batch pull request merges.

With Batch merging on, /kosuke:ship in a task session still runs /kosuke:review and full QA. The task's branch is not synced with its Target Branch.

What it does​

  1. It reads the open pull requests on GitHub and each task session's facts: its GitHub review decision and approvals, its go-ahead and the commit it was given on, the commit QA passed on, its QA Report and how many batches left it out. It decides which go in. A pull request with no approval or go-ahead on its latest commit, whose QA did not pass on that commit, a draft, with red CI on its latest commit, or with changes requested stays out, and the batch pull request names the reason. One left out of two batches stays out until its member decides.
  2. It groups pull requests that change the same files. A group goes in whole or stays out whole. Every pull request that can go in does, with no limit on the count, merged oldest first.
  3. It merges each pull request's latest commit with a merge commit, one at a time, without rewriting it, and labels the task's session in batch. It resolves conflicts by what each pull request's description asks for. After the last merge, it renumbers a colliding migration with the project's migration tool, never changing its content, and rebuilds generated files, such as lockfiles and API snapshots, once with the project's own tools.
  4. It runs lint, type checks, tests related to its own resolutions and commits, and every generator drift check before pushing the draft; CI runs the full suites and gates readiness.
  5. It opens the batch pull request as a draft. The description lists each merged pull request, each one left out with its reason, and each conflict it resolved.
  6. It runs /kosuke:review on what it wrote itself, its conflict resolutions and its own commits, and fixes the findings. Each task's own code was already reviewed in its session.
  7. It runs a short QA while CI runs, usually under 20 minutes. It tests the QA items of each pull request that touch files two or more pull requests change, or files the batch resolved, plus a few checks of the project's core flows from the Project QA Guide. Generated files, such as OpenAPI specs and generated types, do not count: almost every change regenerates them. When the pull requests share no other file and the batch resolved nothing itself, it runs only the core-flow checks.
  8. After CI passes, it marks the batch pull request ready for review. Then it records each task's pull request in the batch and closes it, so no other batch takes it. The task stays under review until the batch merges.

After pushing its draft, the batch takes no new pull requests and runs scoped QA while CI runs; when checks are still running, it ends its turn and Kosuke wakes it when they finish. After an eject or rebuild, it runs the same light local checks, pushes, and lets CI run the full suites.

Pipelined batches​

Once the current batch has pushed its draft, Kosuke can start the next batch on top of it with the pull requests waiting. At most two batches are open: the current one and one pipelined batch. Both pull requests target the project's Target Branch.

While the current batch is open, the next stays a draft. When the current batch merges unchanged, the next keeps its checks and QA and can become ready without running them again. When the current batch changes or ends without that merge, the next is rebuilt on the new base and checked and QA'd again.

When a pull request fails​

When a QA item fails, the batch first finds what causes it. When the item passed in the pull request's own QA at the same commit, the batch retests it and looks for the merge that broke it, so the pull request whose lines cause the failure is the one that pays. A minor failure does not leave a pull request out: the batch lists it on the batch pull request and comments it on the pull request that caused it.

When a pull request breaks a check or a critical or major QA item, or its conflict cannot be resolved safely, the batch leaves it out:

  • The pull request goes back to draft and gets a comment with the reason and evidence. It is reopened first when the batch had closed it. Its task loses the in batch label.
  • Its own task session gets the reason and fixes it. Its QA pass and go-ahead name the old head, so the next batch takes it once QA passes and it is approved again on the new one.
  • The batch rebuilds its branch without that pull request and checks the rest again. A pull request left out only because of it, by a conflict or a shared file, goes back in.

When batches leave the same pull request out twice, its agent stops and asks its member how to go on.

What you get​

  • One pull request, ready for review, whose QA passed on its latest commit.
  • A reply that lists the merged pull requests, the ones left out with their reasons, the review's findings, the QA result with its QA Report, and the link to the pull request.
  • A Sensei card for every owner and admin of the workspace, since a batch belongs to no member. It says the batch is ready to merge, merged nothing, or failed, and why. A later message about the same batch updates the card.

A task carries the in batch Session Label while a batch holds its pull request. When the batch ends, however it ends, Kosuke takes the label off that batch's tasks.

When you merge the batch pull request, each task in it is completed. When the batch ends without merging, Kosuke reopens its tasks' pull requests.

When every pull request is left out, the batch ends with nothing to merge. Kosuke does not start another batch for the same pull requests for an hour. Sooner, it starts when one changes, its QA passes again, it gets a go-ahead, or another one waits, and the reply says why each was left out. The Batch merging row in project settings says so too.

When a batch fails on its own work, it ends, and the same hour-long wait applies. Its pull request goes back to draft with a comment saying why, so nobody merges a batch that did not finish.

Limits​

  • It never merges the batch pull request. You merge it.
  • It never rebases, squashes or rewrites a task's pull request, and never pushes to its branch.
  • It closes a task's pull request only once the batch pull request is ready, after recording it in the batch.
  • It reviews and fixes only what the batch itself wrote, such as a conflict resolution. A defect in a task's own code goes back to that task.

Next steps​