chadtmiller.com/knotless

Switch repository

Loading…

What changes

A pull's merge box sets it to merge when its checks pass, as knotless pull merge --auto does (Pulls can be set to merge by themselves once their checks pass, which this stacks on). While its checks run or fail, the owner and collaborators get Merge when checks pass as the primary button, on a branch with no merge queue in a repository that names runners. Once it is set, a row at the top says "Merges when checks pass" and who set it, and Cancel merge takes it back, for its author too. A push from someone who may not merge it, or retargeting it, shows "Merge cancelled" and why.

API. dev.knotless.setAutoMerge {repo, pull, undo} sets it or cancels it. getMergeStatus gains may.autoMerge and autoMerge {state, by, pushedBy}, with each account as the pages show one.

Why

This is the follow-up to taking the merge queue off by default. Without a queue rule, nothing held a pull until its checks passed, so someone had to come back and merge it.

How it was checked

• The gateway serve test sets it, refuses a stranger, shows it retargeted and set again, and cancels it.
• The forge test gauges a pull its fork's author pushed to.
• A new e2e flow sets and cancels it on bob's fork pull, and reads alice's records back.
• just lex passes, and svelte-check shows 0 errors.
• The attached pictures, from just look, show the offer, set (alice's view and the author's view), set while conflicting, and cancelled by a push.

The recorded answers have no autoMerge, so no shot moves.

Shortcomings

• The shots world records no pull with it set, so the check draws none of these states. The pictures here show them.
• The e2e flow assumes bob's fork pull is not clean yet. CI tells.

This adds the pages' side of merge when checks pass:

• A dev.knotless.setAutoMerge route, with a lexicon and an API doc entry.
• may.autoMerge and autoMerge {state, by, pushedBy} on getMergeStatus, with the accounts resolved as the pages show them.
• A merge-box offer, a "Merges when checks pass" row, a "Merge cancelled" row and a Cancel merge button.

I read every changed file and found nothing that must change. The gate in may() matches the lexicon and docs: maintainer, runners present, no queue-only base. Cancelling is open to the pull's author through may.head, as documented. The tests cover set, a stranger refused, retarget and re-set, and cancel. The change file is present.

I did not read the check results, so the stated e2e assumption that bob's fork pull is not clean yet is unverified here.

One small thing in docs/reference/api.md: may.autoMerge and the top-level autoMerge share a name in one run-on sentence, so the doc is harder to read than it needs to be. Splitting them into two sentences would help.

Carried forward: the change this pull makes at 3395ad539160b70b2e6381275a9be9cc13dc832f is the one reviewed at ca3fbef837ca8b1598fcd25ff34e1e4eac64d089, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at d5fac4f97cf471cf06a1e392e765752b079afa41 is the one reviewed at 3395ad539160b70b2e6381275a9be9cc13dc832f, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at 73fb93b43d129dfd9b2f92a1e21f6e661634cc59 is the one reviewed at d5fac4f97cf471cf06a1e392e765752b079afa41, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at 4ff310943131da16cac3dbc6ab02f1b3cd23d221 is the one reviewed at 73fb93b43d129dfd9b2f92a1e21f6e661634cc59, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at d4122ef6a43ca3a6646093c92a11b337a483b212 is the one reviewed at 4ff310943131da16cac3dbc6ab02f1b3cd23d221, so that review stands. What is new comes from its base.

My earlier approval at d4122ef6 stands. Since then the branch has the new e2e setup, a forge test assertion, and a merge of main.

• e2e flow: bob now commits a pull workflow to his fork branch, so the pull has a check to wait for. This answers the "assumes bob's fork pull is not clean yet" shortcoming. alice then sets and cancels the merge, and the flow reads her dev.knotless.autoMerge records back.
• Forge test: it asserts that --check after a push from someone who may not merge reports no "merges when its checks pass". That matches the cancelled-by-push state the pages show.
• Merge of main: the only conflict was in forge.rs. The pull_diff for the pull shows only this feature's files, so main's changes are not in it.

I did not read the check results. Whether the e2e flow passes in CI is unverified here.

The docs/reference/api.md run-on sentence about may.autoMerge and the top-level autoMerge is still there. I mentioned it last round, and it doesn't block merging.

Carried forward: the change this pull makes at e59a552c09ba80ae4c962b2417c53c7ef5a8e1d5 is the one reviewed at 0d0d4668bed5d262d652dfb0187e39090dfa9821, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at 413a5fc4e965fa57caf188760923632bf064f31a is the one reviewed at e59a552c09ba80ae4c962b2417c53c7ef5a8e1d5, so that review stands. What is new comes from its base.

Carried forward: the change this pull makes at 8c3e0edcfb74bd76e1bd972f03d49d5193c6f921 is the one reviewed at 413a5fc4e965fa57caf188760923632bf064f31a, so that review stands. What is new comes from its base.