Fix canary build links with a rebuilt UI - #860
Merged
Merged
Conversation
Pressing install on a row of the canary list, from a device running a stable release, opened the update page on the stable release that device was already running. The channel is derived from the running build, and a reader on a release build is never offered a canary. That part is right, and it is what the version text on the home screen asks for. It was implemented by dropping the canaries out of the list the update page reads, which is not the same thing. The canary list hands that page a build by version code; the page looked the number up in a list the number had been filtered out of, found nothing, and fell through to its default — the newest release. So the one screen whose purpose is to point people at prereleases was the one screen that could not reach one. The state now keeps `catalog`, every published build from both channels, and `history` becomes a view of it narrowed to the reader's channel. Nothing about what is *offered* changes: `available` is still computed release-only for a release reader, so the home card and the version text behave exactly as before. Only an explicit request resolves against the whole catalogue. Asking for a build by name is not the same as being nudged towards one. The version picker follows the page rather than the device for the same reason. A page opened on a canary lists every build, so there is a way back to the row the reader arrived from; before, it would have answered with the stable list and no route to the prerelease they had just chosen.
The canary page was a worse copy of the build page. Each row carried the zip names, their sizes and an install button — all of which the build page does properly, since it states the sizes, remembers which variant was last taken, checks the root implementation and shows the installer's own output. What the row did not carry was any reason to install it: not the date, not what the build was, not whether the reader was already running it. So the page now chooses rather than installs. A row is the build's head commit — its subject, wrapped rather than clipped, and who wrote it, in the accent colour when that is somebody other than the maintainer, exactly as the commit rail marks a contribution. Its pull request sits in a fixed corner of the card, measured to hold five digits so that reserving it cannot re-wrap the subject beside it, and tapping it opens the discussion rather than the build. The marker from the commit rail shows where the reader sits among the builds, and the rest of the card is one tap to the page that installs it. The head commit is matched by SHA, not by version code: `globalIndex` is assigned by counting down across a paged fetch and its own documentation warns that a lost page leaves the numbers below the seam reading high, while a release names its commit exactly. When the feed cannot reach that commit the subject comes from the release notes instead, where CI writes it as the first bold line. The headline is what has been fixed since the reader's build, named issue by issue. That cannot come from the commits: an issue linked through GitHub's Development panel is closed by the merge and writes nothing into any commit message, and the link itself is only readable through `PullRequest.closingIssuesReferences` in GraphQL, which answers 403 without an account — this app has none by design, which is the same reason the canaries are prereleases rather than Actions artifacts. The issues endpoint answers the neighbouring question anonymously, so the screen asks that one and says exactly what it got back: issues closed as `completed` since the running build was cut. Not `not_planned`, not `duplicate` — a fifth of one page here — and never a zero, because an empty answer means the request failed or the build could not be dated, and printing it as "0 fixed" would turn that into a discouraging fact. Three sentences about the reader's own position, because a version code is a commit count and not an identity. A build wearing the newest canary's number without being it is told so rather than congratulated, which is what the card below it already said; a build past every canary is a local one only if the reader is on the canary channel, and otherwise it is simply a release published after the last nightly, which is the normal state for a day or two after every release. `CanaryBuild` is gone. It was a second shape over the release list the update page already holds, so the page fetched what was in memory and could still say nothing about a build — no notes, no commit, and so no way to mark the one that is running. The canary list is now that catalogue filtered, which also means the one request this screen adds is the issue list and nothing else.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On a release build, pressing install on a canary opened the newest release. The channel rule that keeps nightlies out of the update card also filtered the list an explicit request was resolved against, so the version code the canary list passed matched nothing and the selection fell back to the channel default. That rule now filters what is offered, not what can be asked for by name.
The canary page is rebuilt around the builds themselves. Each row is the build's head commit — subject wrapped, author credited, pull request in a fixed corner that opens the discussion — matched by SHA, falling back to the subject CI writes into the release notes. The header names the issues closed since the running build was cut, read from the issues endpoint filtered to
completed: the Development panel closes issues without writing to any commit message, and the link itself exists only in GraphQL, which needs an account. The commit rail's marker shows where the running build sits, and a build wearing a canary's number without being it is told so.