New electron-updater #3084
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,15 +1,19 @@ | ||
| import {autoUpdater} from "electron-updater" | ||
| import {Updater} from "./types" | ||
| import semver from "semver" | ||
| import {app, shell} from "electron" | ||
| import env from "src/app/core/env" | ||
| import links from "src/app/core/links" | ||
| import pkg from "src/electron/pkg" | ||
|
|
||
| autoUpdater.autoDownload = false | ||
| autoUpdater.autoInstallOnAppQuit = false | ||
| autoUpdater.forceDevUpdateConfig = true | ||
|
|
||
| export class LinuxUpdater implements Updater { | ||
| async check() { | ||
| const {updateInfo} = await autoUpdater.checkForUpdates() | ||
| const latest = updateInfo.version | ||
| const current = app.getVersion() | ||
|
Comment on lines
+1
to
+16
There was a problem hiding this comment. This is the big payoff. What I'm adding here plus the code removal in this same file effectively drops our old "Linux update helper" (the one that tried to look for a newer macOS release as a sign that a newer Linux release is surely available as well) and allows us to use the autoUpdater to check for the latest Linux release. This approach became possible when FWIW, I did test out the "beta" support for true Linux autoUpdate and it didn't work for me, complaining of sha512 checksum mismatch between the build itself and its metadata. Since the scope of my testing/changes was already significant enough, plus it's a "beta" feature after all, I chose to not dig further into that for now and instead maintain feature parity with what we already provide on Linux, i.e., check for a newer release and pop up a notification, but clicking Install just brings up the page in the user's browser where they can download the latest. I recognize that I'm effectively duplicating some code from |
||
| if (semver.lt(current, latest)) { | ||
| return latest | ||
|
|
@@ -22,19 +26,6 @@ export class LinuxUpdater implements Updater { | |
| shell.openExternal(this.downloadUrl()) | ||
| } | ||
|
|
||
| private downloadUrl() { | ||
| if (env.isInsiders) { | ||
| return pkg.repository + "/releases/latest" | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ import {getMainObject} from "src/core/main" | |
|
|
||
| autoUpdater.autoDownload = false | ||
| autoUpdater.autoInstallOnAppQuit = false | ||
| autoUpdater.forceDevUpdateConfig = true | ||
|
There was a problem hiding this comment. I previously had not been using it since I always opt to test in personal fork repos, but during my test work I became aware of the |
||
|
|
||
| export class MacWinUpdater implements Updater { | ||
| async check() { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During #3082 debug, at one point I'd advanced the
electron-updaterdependency to the latest (6.2.1) just to see if any of the problems I'd observed had already been fixed. What I found was that Zui Insiders auto-updates actually broke in places like they used to work before, such as macOS.I debugged further by putting tons of console debug logging in the
electron-updater/out/providers/GitHubProvider.jsfor both our old and the lastestelectron-updaterversions (GitHubProvider.js.4.3.8.gz and GitHubProvider.js.6.2.1.gz, respectively). What this revealed is that the "channels" support added inelectron-updaterv5 did not play nice with the way we'd been creating prerelease version strings in Zui Insiders. Specifically, while the lone trailing digits like inv1.7.1-24are legal per the semver spec and the spec says "Identifiers consisting of only digits are compared numerically", the debug output showed thatelectron-updaterwas treating the trailing digits as the "channel name" (i.e., channel name24in this case) and so the lack of any further numbers after that channel name (e.g.,-24.1,-24.2) meant that once running a Zui Insiders prerelease version the autoUpdater would not see any of the higher-numbered prereleases (e.g.,-25,-26, etc.) as eligible update targets.Thankfully, a solution did reveal itself, and that's to lean into the channel feature. In addition to the "official" supported channel names like
alphaandbeta,electron-updatealso supports "custom" channel names, such as I'm doing here, which results in release version strings likev1.7.1-insiders.24. That makes it happy since it findsinsidersas the channel name and24as a version that testing confirms is treated like a number (e.g., a-insiders.9release does see an-insiders.10release as an eligible update target).We're not currently trying to do anything fancy with channels (e.g., maintain separate
alphaandbetachannels, let users bounce between channels, downgrade, etc.) and since testing confirms that this one change gets us to what we need I'm keen to make the minimal change for the maximum benefit. Another lemonade-from-lemons effect is that the presence of the explicitinsidersin the version string is another nice self-documenting way to know if a user is running Insiders rather than regular Zui, such as if they're pinging us for Support and we ask them to show their version string from About.