release-desktop.sh
One-shot pipeline.
The release script bumps the version, builds the binary + installer, tags git, and uploads everything to GitHub. One command, one new release that the auto-updater finds. Grit scaffolds this as scripts/release-desktop.sh.
The full pipeline
$scripts/release-desktop.sh 1.2.3
That runs:
- Bump
wails.json'sproductVersion+outputfilename - Bump
version.go'sAppVersionconstant - Regenerate branded NSIS bitmaps from
icon.ico - Download + cache the offline WebView2 runtime (first time only)
wails build -nsis -platform windows/amd64 -trimpath -ldflags '-s -w'- Run
makensison the slim variant - Tag
v1.2.3+ git push gh release createwith three assets (raw .exe, full installer, slim installer)
Prerequisites
bash,jq,python3on PATH (Git Bash on Windows gives you all)wailsCLImakensis— Windows NSIS installgh— GitHub CLI, signed in (gh auth login)powershell.exeon PATH (needed for the bitmap generation step)
Versioning
Semantic versioning:
v1.0.0 Initial releasev1.0.1 Bug fix onlyv1.1.0 New feature, backward-compatiblev2.0.0 Breaking change
For internal-only POS apps, you can be looser — many shops just use date-based versions like 2026.06.12. The important rule is that versions sort lexically + the auto-updater recognises a higher value as newer.
Three assets per release
- Raw .exe (
FieldPOS-v1.2.3.exe) — what the auto-updater downloads and swaps. ~15 MB. - Full installer (
FieldPOS-Setup-v1.2.3.exe) — ~150 MB with bundled WebView2 runtime. Customer-facing. - Slim installer (
FieldPOS-Setup-Slim-v1.2.3.exe) — ~22 MB, downloads WebView2 online. Easier email attachment.
GitHub Actions alternative
For teams, automate via GitHub Actions instead of running the script locally:
on:push:tags: ['v*']jobs:release:runs-on: windows-lateststeps:- uses: actions/checkout@v4- uses: actions/setup-go@v5- uses: pnpm/action-setup@v2- run: go install github.com/wailsapp/wails/v2/cmd/wails@latest- run: choco install nsis -y- run: scripts/release-desktop.sh ${{ github.ref_name }}env:GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Push a tag locally, GitHub Actions runs the same script in CI, the release appears on the Releases page, every running v1 binary sees the new release on its next 6-hour check.
Code signing — optional but worth it
An unsigned .exe shows the Windows SmartScreen warning the first time a customer runs it. A code-signing cert (~$200/year) skips this. Add a signing step to the script:
signtool sign /f cert.pfx /p "$CERT_PWD" /tr http://timestamp.digicert.com /td sha256 /fd sha256 \"build/bin/FieldPOS-v$VERSION.exe"
Quick check
Try it
For chapter 4's assignment, ship a release:
- Install v0.1.0 of your scaffolded app via the installer
- Make a small visible change (change a label, add a route)
- Run
scripts/release-desktop.sh 0.1.1 - Confirm v0.1.1 appears on
github.com/<you>/<repo>/releaseswith 3 assets - Open the installed v0.1.0 — the "Update available" banner should appear
- Click Install & restart. App relaunches as v0.1.1.
What's next
Final chapter — Branded installers. NSIS deep dive: full vs slim variants, branded MUI bitmaps from your icon.
Spot a typo? Have an idea?
Help us improve this lesson. One click opens a GitHub issue with the lesson URL pre-filled — suggest clearer wording, report a bug, or request more depth. The course keeps improving thanks to learners like you.
Suggest an improvement on GitHub