* Add linux makers * missed some * remove eu-strip * blah * add description * remove v from version * add exec name * use bin * add bin to both * test flatpak * test adding dev dependencies * remove flatpak for now * add command to flatten directory structure * update package info * save rpm info * save work * add bin to packagerConfig * save work * okay let's see what happens * iterate array * test more * remove large * test * test * remove linux arm * test addl targets * add quiet to zip * revert dir flatten * remove pacman * add s3 bucket to electron-builder config * make dir * only copy artifacts * don't merge * zip recurse * blah * replace with electronupdater * make generic * fix * fix stuff * Update build-helper.yml * test fix * fix path * remove tree * messed up comment * remove touch * add platform name to artifact * remove license * remove forge * cleanup builder config * switch artifact name order * Remove darwin restriction on autoupdate * try adding back pacman * fix license * remove pacman again * rewrite scripts * add binary paths to builder * clean up * Update scripts * update interval and readme * remove flatpak and snap dependencies for now * upload with a wildcard * fix paths for addl binaries * add back blockmap * update release path * add newline * remove forge config * 2 small fixes - remove double cd for waveshell building, and remove GOARCH for wavesrv binary in dev mode
3.3 KiB
Building for release
Build Helper workflow
Our release builds are managed by the "Build Helper" GitHub Action, which is defined
in build-helper.yml
.
Under the hood, this will call the build-package
and build-package-linux
scripts in
scripthaus.md
, which will build the Electron codebase using
WebPack and then the wavesrv
and mshell
binaries, then it will call electron-builder
to generate the distributable app packages. The configuration for electron-builder
is electron-builder.config.js
.
We are working to fully automate the building of release artifacts. For now, manual steps are still required to sign and notarize the macOS artifacts. The Linux artifacts do not require additional modification before being published.
Local signing and notarizing for macOS
The prepare-macos.sh
script will download the latest build
artifacts from S3 and sign and notarize the macOS binaries within it. It will then
generate a DMG and a new ZIP archive with the new signed app.
This will call a few different JS scripts to perform more complicated operations.
osx-sign.js
and osx-notarize.js
call
underlying Electron APIs to sign and notarize the package.
update-latest-mac.js
will then update the latest-mac.yml
file with the SHA512 checksum and file size of the new signed and notarized installer. This
is important for the electron-updater
auto-update mechanism to then find and validate new releases.
Uploading release artifacts for distribution
Upload script
Once the build has been fully validated and is ready to be released, the
upload-release.sh
script is then used to grab the completed
artifacts and upload them to the dl.waveterm.dev
S3 bucket for distribution.
Homebrew
Homebrew currently requires a manual bump of the version, but now that we have auto-updates, we should add our cask to the list of apps that can be automatically bumped.
Linux
We do not currently submit the Linux packages to any of the package repositories. We are working on addressing this in the near future.
electron-build
configuration
Most of our configuration is fairly standard. The main exception to this is that we exclude our Go binaries from the ASAR archive that Electron generates. ASAR files cannot be executed by NodeJS because they are not seen as files and therefore cannot be executed via a Shell command. More information can be found here.
We also exclude most of our node_modules
from packaging, as WebPack handles packaging
of any dependencies for us. The one exception is monaco-editor
.
Automatic updates
Thanks to electron-updater
, we are able to provide automatic app updates for macOS and Linux,
as long as the app was distributed as a DMG, AppImage, RPM, or DEB file.
With each release, latest-mac.yml
and latest-linux.yml
files will be produced that point to the
newest release. These also include file sizes and checksums to aid in validating the packages. The app
will check these files in our S3 bucket every hour to see if a new version is available.