feat(desktop): publish releases to a dedicated update channel - #89
Conversation
electron-updater's public GitHub provider resolves the repository's newest release. This repository publishes CLI releases continuously, so that is almost always a CLI release carrying no latest-mac.yml, and every desktop update check fails. Publish desktop releases to PyModel/pythinker-desktop-releases instead, where the latest release always describes the desktop app. Releases are created with releaseType: release because the publisher otherwise creates a draft, and a draft is invisible to the updater. Publishing across repositories needs an installation token; GITHUB_TOKEN cannot reach another repository. There is deliberately no fallback: a fallback would publish to the wrong repository and silently restore the bug this fixes, so a missing secret fails the release. Both jobs now also assert that app-update.yml is present inside the packaged application. Without it a build cannot self-update, and the app reports itself as non-updatable, so shipping one is a silent regression.
|
Warning Review limit reached
Next review available in: 14 minutes Limit details: You’ve used all 3 included reviews currently available under your plan. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Comment |
commit: |
1 participant
Related Issue
Follow-up to #87, which fixed the desktop update client. This fixes the update channel.
Problem
Auto-update is broken in shipped desktop builds, independently of the client-side bugs fixed in #87.
electron-updater's public GitHub provider resolves the repository's newest release. This repositorypublishes CLI releases continuously, so
https://github.com/PyModel/pythinker-code/releases/latestresolves to a CLI release — currently
@pymodel/pythinker-code@0.19.0— which contains no desktopassets and no
latest-mac.yml. Every desktop update check therefore 404s.One repository was publishing two unrelated release streams into one "latest" channel.
What changed
PyModel/pythinker-desktop-releases, a repository that holdsdesktop artifacts and update metadata only, so "latest release" unambiguously means the desktop app.
releaseType: "release"is set explicitly.electron-publish's GitHub publisher otherwisecreates a draft, and a draft is invisible to the updater — this would have failed quietly.
GITHUB_TOKENisscoped to the repository running the workflow and cannot publish into another one.
app-update.ymlexists inside the packaged application. A build without itcannot self-update, and after fix(desktop): pin the Host port and stop reporting non-updatable builds as errors #87 the app reports itself as non-updatable rather than erroring — so
shipping such a build would be a silent regression. The check is the last command in its step, so a
missing file fails the job.
Required before the next desktop release
Two repository secrets, from a GitHub App installed on
PyModel/pythinker-desktop-releaseswithContents: write:
DESKTOP_RELEASES_APP_IDDESKTOP_RELEASES_APP_PRIVATE_KEYThere is deliberately no fallback to
GITHUB_TOKEN. A fallback would publish to the wrongrepository and silently recreate this bug; a missing secret must fail the release loudly instead.
Nothing breaks before then — this workflow only runs on
desktop-v*tags.Alternatives considered and rejected
code.pythinker.comCDN. Needs its own credential and atomicpublishing, cache-control correctness, and availability monitoring that the GitHub path gets free.
allowPrereleaseand adesktopchannel. This can be made to work withsemver-valid tags, since the provider scans the Atom feed and skips invalid tags. Rejected because
Atom retention is not a channel contract: enough CLI releases can push every desktop entry out of
the feed, and the failure returns silently.
Migration note
Clients on the existing
v0.1.0pre-release cannot learn about the new repository and will need onemanual reinstall. That cost is already sunk — their update path is broken today regardless — and it
only grows with the installed base, which is why this moves now rather than later.
Verification
pnpm --filter @pymodel/pythinker-desktop exec vitest run— 80 passed, including a newassertion that the publish target is the releases repo with
releaseType: release. Recorded redagainst the old config first.
pnpm run lint— exit 0.on
GITHUB_TOKEN, and a packaged-feed guard in both jobs.Checklist
gen-changesetsskill, or this PR needs no changeset. —@pymodel/pythinker-desktopis private and changeset-ignored.gen-docsskill, or this PR needs no doc update.