5b7535d08f
## New release flow
1. Run "Bump Version" workflow with the desired version bump and the
prerelease flag set to `true`. This will push a new version bump to the
target branch and create a new git tag.
- See below for more info on how the version bumping works.
2. A new "Build Helper" workflow run will kick off automatically for the
new tag. Once it is complete, test the new build locally by downloading
with the [download
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/download-staged-artifact.sh).
3. Release the new build using the [publish
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/publish-from-staging.sh).
This will trigger electron-updater to distribute the package to beta
users.
4. Run "Bump Version" again with a release bump (either `major`,
`minor`, or `patch`) and the prerelease flag set to `false`.
6. Release the new build to all channels using the [publish
script](https://github.com/wavetermdev/thenextwave/blob/main/scripts/artifacts/publish-from-staging.sh).
This will trigger electron-updater to distribute the package to all
users.
## Change Summary
Creates a new "Bump Version" workflow to manage versioning and tag
creation.
Build Helper is now automated.
### Version bumps
Updates the `version.cjs` script so that an argument can be passed to
trigger a version bump. Under the hood, this utilizes NPM's `semver`
package.
If arguments are present, the version will be bumped.
If only a single argument is given, the following are valid inputs:
- `none`: No-op.
- `patch`: Bumps the patch version.
- `minor`: Bumps the minor version.
- `major`: Bumps the major version.
- '1', 'true': Bumps the prerelease version.
If two arguments are given, the first argument must be either `none`,
`patch`, `minor`, or `major`. The second argument must be `1` or `true`
to bump the prerelease version.
### electron-builder
We are now using the release channels support in electron-builder. This
will automatically detect the channel being built based on the package
version to determine which channel update files need to be generated.
See
[here](https://www.electron.build/tutorials/release-using-channels.html)
for more information.
### Github Actions
#### Bump Version
This adds a new "Bump Version" workflow for managing versioning and
queuing new builds. When run, this workflow will bump the version,
create a new tag, and push the changes to the target branch. There is a
new dropdown when queuing the "Bump Version" workflow to select what
kind of version bump to perform. A bump must always be performed when
running a new build to ensure consistency.
I had to create a GitHub App to grant write permissions to our main
branch for the version bump commits. I've made a separate workflow file
to manage the version bump commits, which should help prevent tampering.
Thanks to using the GitHub API directly, I am able to make these commits
signed!
#### Build Helper
Build Helper is now triggered when new tags are created, rather than
being triggered automatically. This ensures we're always creating
artifacts from known checkpoints.
### Settings
Adds a new `autoupdate:channel` configuration to the settings file. If
unset, the default from the artifact will be used (should correspond to
the channel of the artifact when downloaded).
## Future Work
I want to add a release workflow that will automatically copy over the
corresponding version artifacts to the release bucket when a new GitHub
Release is created.
I also want to separate versions into separate subdirectories in the
release bucket so we can clean them up more-easily.
---------
Co-authored-by: wave-builder <builds@commandline.dev>
Co-authored-by: wave-builder[bot] <181805596+wave-builder[bot]@users.noreply.github.com>
3.7 KiB
Building for release
Bump Version workflow
All releases start by first bumping the package version and creating a new Git tag. We have a workflow set up to automate this.
To run it, trigger a new run of the Bump Version workflow. When triggering the run, you will be
prompted to select a version bump type, either none, patch, minor, or major, and whether the version is prerelease or not. This determines how much the version number is incremented.
See version.cjs for more details on how this works.
Once the tag has been created, a new Build Helper run will be automatically queued to generate the artifacts.
Build Helper workflow
Our release builds are managed by the Build Helper workflow.
Under the hood, this will call the package task in
Taskfile.yml, 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.cjs.
This will also sign and notarize the macOS app package.
Once a build is complete, it will be placed in s3://waveterm-github-artifacts/staging-w2/<version>.
It can be downloaded for testing using the download-staged-artifact.sh
script. When you are ready to publish the artifacts to the public release feed, use the
publish-from-staging.sh script to directly copy the artifacts from
the staging bucket to the releases bucket.
You will need to configure an AWS CLI profile with write permissions for the S3 buckets in order for the script to work. You should invoke the script as follows:
<script> <version> <aws-profile-name>
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, latest-linux.yml, and latest-linux-arm64.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.
Update channels
We utilize update channels to roll out beta and stable releases. These are determined based on the package versioning described above. Users can
select their update channel using the autoupdate:channel setting in Wave. See here for more information.
Homebrew
Homebrew is automatically bumped when new artifacts are published.
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 Vite handles packaging
of any dependencies for us. The one exception is monaco-editor.