mirror of
https://github.com/wavetermdev/waveterm.git
synced 2025-01-02 18:39:05 +01:00
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>
70 lines
3.7 KiB
Markdown
70 lines
3.7 KiB
Markdown
# 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](https://github.com/wavetermdev/thenextwave/actions/workflows/bump-version.yml). 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`](../../version.cjs) for more details on how this works.
|
|
|
|
Once the tag has been created, a new [Build Helper](#build-helper-workflow) run will be automatically queued to generate the artifacts.
|
|
|
|
## Build Helper workflow
|
|
|
|
Our release builds are managed by the [Build Helper workflow](https://github.com/wavetermdev/thenextwave/actions/workflows/build-helper.yml).
|
|
|
|
Under the hood, this will call the `package` task in
|
|
[`Taskfile.yml`](../../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`](../../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`](./download-staged-artifact.sh)
|
|
script. When you are ready to publish the artifacts to the public release feed, use the
|
|
[`publish-from-staging.sh`](./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:
|
|
|
|
```bash
|
|
<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](#bump-version-workflow). Users can
|
|
select their update channel using the `autoupdate:channel` setting in Wave. See [here](https://www.electron.build/tutorials/release-using-channels.html) 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](https://www.electronjs.org/docs/latest/tutorial/asar-archives#executing-binaries-inside-asar-archive).
|
|
|
|
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`.
|