chadtmiller.com/knotless

Switch repository

Loading…

What changes

A sidebar on New issue and Open a pull, as GitHub's create pages have. Labels, each picked from a gear menu, of those the account may put on the repository's pulls and issues; and on a pull, Reviewers, from the owner and collaborators besides the one opening it. Picking an exclusive label drops the others of its scope, as labelling does. The sidebar shows only to someone who has something to pick, and on a phone it comes above the form.

Open a pull compares first, as GitHub's compare page does: the branches, a line saying what the branch brings in, and its commits and diff, with an Open pull button that unfolds the form and sidebar in place. Compare & pull on a branch's files links with expand=1, which shows the form at once, as GitHub's banner does.

The writes. createIssue and createPull take labels (each {name}, a new dev.knotless.defs#labelName), and createPull takes reviewers (each dev.knotless.pull#reviewer), through the same code as knotless label and knotless pull --reviewer. A label the account may not put on is refused before anything is written, so a refusal never leaves the issue behind without it. labelItem's labelling is now a function the three share.

What the account may put on. getRepo's viewer gains labels: those the repository defines that the asker may put on, as the owner, a collaborator or a triager of their scopes.

Why

An issue or pull could only be labelled, and a pull's reviewers asked for, after it was opened, from its own page or the command line.

How it was checked

A gateway test (opening_pulls_and_issues_from_the_pages) opens a pull asking a reviewer, and an issue and a pull with a label as the owner; the fan asking for one is refused, and getRepo offers the owner the label and the fan none. Two e2e flows: bob unfolds the form from the compare and asks alice to review the pull he opens from his fork, and alice opens an issue with kind/bug. just lex passes; svelte-check. just look of New issue with a label picked Open a pull with a reviewer asked, and the compare before its form unfolds, desktop light and phone dark, below: no recorded page draws the sidebar, since no recording holds viewer.labels or the new-item pages.

Shortcomings

Reviewers are picked from the owner and collaborators only (the first twenty getRepo names), not anyone on the Atmosphere, which knotless pull --reviewer can still ask. No server build or test was run here: CI runs them.

🤖 Generated with Claude Code

This adds a labels and reviewers sidebar to New issue and Open a pull. createIssue and createPull take labels, and createPull takes reviewers. getRepo's viewer gains labels. The labelling code is now shared as labelled. I read the diff and the code around it, and I found nothing that must change.

• Permission check: may_put rejects a label the account may not put on, using the same may_label rule that viewer.labels uses. It runs before the issue or pull is written, so a refused label leaves nothing behind. The gateway test covers this.
• Failure after opening: a failure inside label_opened (the PDS or indexing, not permissions) would still leave the item opened without its labels. That is an unlikely case, and the lexicon text only promises a refusal for labels that are not the account's to put on, which holds.
• Docs and lexicons: docs/design/serve.md and docs/reference/api.md are updated, and the lexicon changes only add optional fields.
• Not checked: I did not read the checks, so I can't say whether CI passed.

Since my last review the pull gained one commit. Open a pull now shows the compare first, with an Open pull button that unfolds the form and sidebar. Compare & pull links add expand=1 to show the form at once. This is web-only: the server, lexicons and the permission checks I reviewed before are unchanged, and docs and the e2e flow are updated to match. I found nothing that must change. My earlier review asked for nothing, so there is nothing to follow up.

The check workflow passed on this commit. The test workflow was still running when I looked, so I can't say whether it passes.

One minor point, not blocking: asked is not reset when the branch or repository selectors change. Once someone has unfolded the form, picking another branch keeps it open instead of returning to the compare. That is harmless.

Since my last review the pull gained one commit. It changes only the private e2e flow (harness/e2e/private.spec.mjs). The flow now checks that the Title box is hidden after choosing the branch, clicks Open pull to unfold the form, and then fills it in. This matches the compare-first behaviour I reviewed before, and I found nothing that must change.

My earlier reviews asked for nothing, so there is nothing to follow up. The check and test workflows on this commit were still queued when I looked, so I can't say whether they pass.