ajandClaude Opus 5.5
277ca36f42
Every installed copy checked GitHub Releases on its own, so a shop's
workstations shared GitHub's 60-requests-per-hour unauthenticated limit
per public address and each downloaded the ~90 MB package over the
internet. Shops large enough to hit that already run the nest server.
The server now mirrors the Velopack feed at /updates/{stable|dev}: one
GitHub API request per 30-minute refresh, each package downloaded once
and checked against the feed's size and SHA-256 before it is served. A
channel is mirrored only while clients ask for it, so stable-only shops
never download development builds. Database-mode clients read the
server first and fall back to GitHub when it has no feed (old server,
mirror off, not mirrored yet), downloading each package from whichever
source listed it. A hand-set feed URL still takes precedence.
OPENNEST_UPDATES=off turns the mirror off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6.4 KiB
Desktop auto-update
The Windows desktop app (OpenNest.exe) can self-update via
Velopack: OpenNest.UpdaterService checks its update
source one minute after startup and every 30 minutes after that, and downloads
a newer release in the background. Once a download finishes, a clickable
status-bar item offers to restart into it; nothing restarts without that
confirmation, so an open, unsaved nest is never discarded automatically.
A download the user does not restart for is applied the next time OpenNest
starts: VelopackApp.Build().Run() in MainApp keeps Velopack's default
SetAutoApplyOnStartup(true), so launching after a download opens the new
version. Nothing runs while OpenNest is closed (no service or scheduled task),
and a session shorter than the first minute never checks.
Help > Check for Updates runs the same check immediately (waiting for a
background check already in progress rather than starting a second one) and
reports the result: already the latest version, the feed was unreachable, or a
downloaded update with the same restart prompt. A copy that is not a Velopack
installation says it cannot update itself and offers to open the GitHub Releases
page. The running version shows at the right of the status bar and in
Help > About OpenNest: Velopack's package version when installed, otherwise
the assembly's informational version without its +commit build metadata.
Where updates come from
By default an installed copy checks the public
GitHub Releases for full,
non-pre-release versions (GithubSource, unauthenticated: GitHub allows 60 API
requests per hour per IP address, ample for a 30-minute poll but shared by every
machine behind one address). Pre-releases are offered only as the development
build below.
Nest server mirror
In Database mode an installed copy reads the nest server's mirror of the same feed first:
{ServerUrl}/updates/stable, or /updates/dev with Include development builds. The
server makes one GitHub check every 30 minutes for every workstation and downloads each
package once, so a shop's machines do not share GitHub's per-address limit or each download
the package over the internet (see the mirror's endpoints).
When the server cannot serve a feed (unreachable, a version without the mirror, mirroring
turned off, or a channel it has not mirrored yet), that check goes to GitHub instead, and the
package downloads from whichever source supplied the feed (ServerFirstUpdateSource). The
source is chosen at startup, so changing storage mode or server takes effect after a restart.
To use a self-hosted feed instead, set Tools > Options > Auto-update feed URL
(OpenNest.Properties.Settings.UpdateFeedUrl, saved for the current Windows
user) to the feed's base URL (http://host:port) and restart. A self-hosted
feed URL is operator infrastructure and never belongs in source control; it takes
precedence over the nest server's mirror, and clearing the field returns to the mirror
(Database mode) or GitHub Releases.
These and the app's other OpenNest.Properties.Settings values live in
%APPDATA%\OpenNest\user-settings.json (AppDataSettingsProvider), shared by every
copy run by that Windows user. .NET's default user.config sat inside the Velopack
install folder, which setup clears on a reinstall, and started empty at each new
assembly version; the first run without the JSON file carries over any values that
copy's user.config still holds.
Velopack only applies updates to a Velopack installation (UpdateManager.IsInstalled):
a copy installed with OpenNest-win-Setup.exe or extracted from
OpenNest-win-Portable.zip. The plain OpenNest.vX.Y.Z.win-x64.zip and ordinary
build output contain no Update.exe and never auto-update; moving from one of
them to an updating copy is a one-time manual install.
Release packages
scripts/Publish-Windows.ps1 packs the same smoke-tested folder as the plain ZIP
with the vpk CLI pinned in .config/dotnet-tools.json (keep it equal to the
Velopack package version), into velopack/: OpenNest-win-Setup.exe,
OpenNest-win-Portable.zip, OpenNest-X.Y.Z-full.nupkg, releases.win.json
and RELEASES, with their hashes in OpenNest.vX.Y.Z.velopack.sha256. Installed
copies find an update through the releases.win.json and full package attached to
the newest full GitHub Release, so all five must be uploaded with it (see
releasing). Packages are full only; delta packages would
need the previous release's packages beside the output before vpk pack.
Development builds
.github/workflows/dev-build.yml runs after every master push whose
Cross-platform tests pass (that workflow includes the Windows desktop tests).
It packages that commit with Publish-Windows.ps1 as X.Y.Z-dev.N, where
X.Y.Z is the minor after the newest vX.Y.Z tag and N the commit count, so
each build outranks the last and the next full release outranks them all. It then
replaces the single rolling dev-build pre-release (tag dev-build, never marked
Latest) with the same eight assets as a release. A run whose commit is no longer
master's head publishes nothing; the newer run does.
Installed copies take it only with Tools > Options > Include development
builds (UpdateIncludeDevBuilds, restart to apply); everyone else sees full
releases only. Velopack reads the ten newest GitHub releases, so keep a single
rolling pre-release: a pile of them could push the newest full release out of
that window. Turning the option off leaves a copy on its development build until
a higher full release appears. The workflow's publish job is the only automation
with release write access; it is limited to this pre-release.
Hosting a feed
Any static file server that can serve a vpk pack output directory works.
scripts/Deploy-OpenNest.ps1 builds a self-contained win-x64 publish,
packs it with the pinned vpk CLI, and scps the
result to a directory you provide:
./scripts/Deploy-OpenNest.ps1 -FeedHost <host> -FeedUser <user> -RemoteDataDir <path>
Bump <Version> in OpenNest/OpenNest.csproj before each run. This is
independent of the GitHub release process and of
Publish-Windows.ps1 — the latter always overrides <Version> via
-p:Version, so the two don't conflict. Machines on a self-hosted feed only see
versions pushed to that feed.