Upstream/waveterm
1
0
Fork 0
mirror of https://github.com/wavetermdev/waveterm.git synced 2024-12-22 16:48:23 +01:00
Code Issues Packages Projects Releases Wiki Activity
e5f98c6475
waveterm/.github/workflows/build-helper.yml

209 lines
10 KiB
YAML
Raw Normal View History

Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
# Build Helper workflow - Builds, signs, and packages binaries for each supported platform, then uploads to a staging bucket in S3 for wider distribution.
# For more information on the macOS signing and notarization, see https://www.electron.build/code-signing and https://www.electron.build/configuration/mac
# For more information on the Windows Code Signing, see https://docs.digicert.com/en/digicert-keylocker/ci-cd-integrations/plugins/github-custom-action-for-keypair-signing.html and https://docs.digicert.com/en/digicert-keylocker/signing-tools/sign-authenticode-with-electron-builder-using-ksp-integration.html
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
name: Build Helper
Fix bugs in electron-builder and build-helper (#1119)
2024-10-24 20:20:25 +02:00
run-name: Build ${{ github.ref_name }}${{ github.event_name == 'workflow_dispatch' && ' - Manual' || '' }}
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
on:
push:
tags:
Evan/v (#392) Co-authored-by: wave-builder[bot] <181805596+wave-builder[bot]@users.noreply.github.com>
2024-09-17 22:37:52 +02:00
- "v[0-9]+.[0-9]+.[0-9]+*"
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
workflow_dispatch:
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
env:
Storybook page, exclude Jotai from dependabot, use NodeJS 20 for builds (#868)
2024-09-26 23:17:52 +02:00
GO_VERSION: "1.22"
Update our build workflows to use NodeJS 22 (#1285) NodeJS 20 is almost EOL so I'm updating our workflows to use NodeJS 22. This does not change anything about our app, which will still use NodeJS 20 until Electron shifts away from it. NodeJS 22 is fully backwards-compatible with NodeJS 20 so there's no issue from a testing standpoint.
2024-11-14 06:06:48 +01:00
NODE_VERSION: 22
Embed static copy of docsite for help view (#949) This will take the latest artifact from the waveterm-docs repo and embed it in the app binary. When the help view is launched, it will be served from our backend. If the embedded copy doesn't exist, such as in unpackaged versions of the app or in locally packaged versions, it will use the hosted site instead. There is a sibling PR in the docs repository to build the embedded version of the app (strips out some external links, removes Algolia DocSearch, updates the baseUrl) https://github.com/wavetermdev/waveterm-docs/pull/46
2024-10-04 05:28:05 +02:00
STATIC_DOCSITE_PATH: docsite
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
jobs:
Move docsite to main repo (#1204) ## Summary We are moving our docsite to this repo for better coordination. ## What's changed? - The docsite codebase is now in docs/ - The docsite will replace storybook as the published GitHub Pages site for this repo - Storybook will now be hosted at https://docs.waveterm.dev/storybook - A new CI workflow will validate any changes to Storybook or the docsite - A combined CD workflow will build and deploy Storybook and the docsite as a single artifact - The Build Helper workflow will now build an embedded version of the docsite before building the app, ensuring the docsite version it has is always the latest
2024-11-06 19:45:21 +01:00
build-docsite:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{env.NODE_VERSION}}
- name: Install Yarn
run: |
corepack enable
yarn install
working-directory: docs/
- name: Build embedded docsite
run: yarn build-embedded
working-directory: docs/
- name: Upload Build Artifact
uses: actions/upload-artifact@v4
with:
name: docsite
path: docs/build
build-app:
needs: build-docsite
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
outputs:
version: ${{ steps.set-version.outputs.WAVETERM_VERSION }}
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
strategy:
matrix:
include:
- platform: "darwin"
Switch to macos-latest runner now that it is ARM (#851)
2024-09-25 21:26:04 +02:00
runner: "macos-latest"
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
- platform: "linux"
runner: "ubuntu-latest"
Enable Linux ARM builds (#127) Adds support for building for Linux ARM targets using the new GitHub Linux ARM64 runners. Adds a new menu item to toggle the visibility of the menu bar on non-darwin targets,
2024-07-20 01:11:08 +02:00
- platform: "linux"
Switch to a larger Linux ARM runner for faster builds (#132)
2024-07-23 01:39:14 +02:00
runner: ubuntu-24.04-arm64-16core
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
- platform: "windows"
runner: "windows-latest"
Setup the Build Helper pipeline (#116) Ports over the Build Helper pipeline from the old app. It will stage to a new S3 bucket for now. I haven't added the auto update yet.
2024-07-18 07:39:22 +02:00
# - platform: "windows"
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
# runner: "windows-11-arm64-16core"
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
runs-on: ${{ matrix.runner }}
steps:
- uses: actions/checkout@v4
- name: Install Linux Build Dependencies (Linux only)
if: matrix.platform == 'linux'
run: |
sudo apt-get update
Use composite action for setup-musl-gcc (#829)
2024-09-25 04:53:57 +02:00
sudo apt-get install --no-install-recommends -y libarchive-tools libopenjp2-tools rpm squashfs-tools
Snap support (#1095) Adds Snap support, though I'm still waiting to hear back from the Snapcraft team about getting our package listed. closes #1092
2024-10-22 03:13:19 +02:00
sudo snap install snapcraft --classic
sudo snap install zig --classic --beta # We use Zig instead of glibc for cgo compilation as it is more-easily statically linked
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
# The pre-installed version of the AWS CLI has a segfault problem so we'll install it via Homebrew instead.
- name: Upgrade AWS CLI (Mac only)
Upgrade AWS CLI on Mac runners to resolve segfault issue (#137) The installed version of the AWS CLI is causing segfaults while uploading binaries to S3. The latest version of the CLI does not appear to have this problem so I am adding a script to upgrade the CLI for Mac targets.
2024-07-23 20:41:52 +02:00
if: matrix.platform == 'darwin'
Don't update all brew dependencies (#950)
2024-10-04 05:43:58 +02:00
run: brew install awscli
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
# The version of FPM that comes bundled with electron-builder doesn't include a Linux ARM target. Installing Gems onto the runner is super quick so we'll just do this for all targets.
- name: Install FPM (not Windows)
if: matrix.platform != 'windows'
Enable Linux ARM builds (#127) Adds support for building for Linux ARM targets using the new GitHub Linux ARM64 runners. Adds a new menu item to toggle the visibility of the menu bar on non-darwin targets,
2024-07-20 01:11:08 +02:00
run: sudo gem install fpm
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
- name: Install FPM (Windows only)
if: matrix.platform == 'windows'
run: gem install fpm
# General build dependencies
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
- uses: actions/setup-go@v5
with:
go-version: ${{env.GO_VERSION}}
cache-dependency-path: |
Setup the Build Helper pipeline (#116) Ports over the Build Helper pipeline from the old app. It will stage to a new S3 bucket for now. I haven't added the auto update yet.
2024-07-18 07:39:22 +02:00
go.sum
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
- uses: actions/setup-node@v4
with:
node-version: ${{env.NODE_VERSION}}
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
- name: Install Yarn
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
run: |
corepack enable
yarn install
Setup the Build Helper pipeline (#116) Ports over the Build Helper pipeline from the old app. It will stage to a new S3 bucket for now. I haven't added the auto update yet.
2024-07-18 07:39:22 +02:00
- name: Install Task
uses: arduino/setup-task@v2
with:
version: 3.x
repo-token: ${{ secrets.GITHUB_TOKEN }}
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
- name: "Set Version"
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
id: set-version
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
run: echo "WAVETERM_VERSION=$(task version)" >> "$GITHUB_OUTPUT"
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
shell: bash
# Windows Code Signing Setup
- name: Set up certificate (Windows only)
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
if: matrix.platform == 'windows' && github.event_name != 'workflow_dispatch'
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
run: |
echo "${{ secrets.SM_CLIENT_CERT_FILE_B64 }}" | base64 --decode > /d/Certificate_pkcs12.p12
shell: bash
- name: Set signing variables (Windows only)
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
if: matrix.platform == 'windows' && github.event_name != 'workflow_dispatch'
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
id: variables
run: |
echo "SM_HOST=${{ secrets.SM_HOST }}" >> "$GITHUB_ENV"
echo "SM_API_KEY=${{ secrets.SM_API_KEY }}" >> "$GITHUB_ENV"
echo "SM_CODE_SIGNING_CERT_SHA1_HASH=${{ secrets.SM_CODE_SIGNING_CERT_SHA1_HASH }}" >> "$GITHUB_ENV"
echo "SM_CLIENT_CERT_FILE=D:\\Certificate_pkcs12.p12" >> "$GITHUB_ENV"
echo "SM_CLIENT_CERT_FILE=D:\\Certificate_pkcs12.p12" >> "$GITHUB_OUTPUT"
echo "SM_CLIENT_CERT_PASSWORD=${{ secrets.SM_CLIENT_CERT_PASSWORD }}" >> "$GITHUB_ENV"
echo "C:\Program Files (x86)\Windows Kits\10\App Certification Kit" >> $GITHUB_PATH
echo "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools" >> $GITHUB_PATH
echo "C:\Program Files\DigiCert\DigiCert Keylocker Tools" >> $GITHUB_PATH
shell: bash
- name: Setup Keylocker KSP (Windows only)
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
if: matrix.platform == 'windows' && github.event_name != 'workflow_dispatch'
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
run: |
Add release channels (#385) ## 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>
2024-09-17 22:10:35 +02:00
curl -X GET https://one.digicert.com/signingmanager/api-ui/v1/releases/Keylockertools-windows-x64.msi/download -H "x-api-key:%SM_API_KEY%" -o Keylockertools-windows-x64.msi
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
msiexec /i Keylockertools-windows-x64.msi /quiet /qn
C:\Windows\System32\certutil.exe -csp "DigiCert Signing Manager KSP" -key -user
smctl windows certsync
shell: cmd
Move docsite to main repo (#1204) ## Summary We are moving our docsite to this repo for better coordination. ## What's changed? - The docsite codebase is now in docs/ - The docsite will replace storybook as the published GitHub Pages site for this repo - Storybook will now be hosted at https://docs.waveterm.dev/storybook - A new CI workflow will validate any changes to Storybook or the docsite - A combined CD workflow will build and deploy Storybook and the docsite as a single artifact - The Build Helper workflow will now build an embedded version of the docsite before building the app, ensuring the docsite version it has is always the latest
2024-11-06 19:45:21 +01:00
- name: Download embedded docsite
uses: actions/download-artifact@v4
Embed static copy of docsite for help view (#949) This will take the latest artifact from the waveterm-docs repo and embed it in the app binary. When the help view is launched, it will be served from our backend. If the embedded copy doesn't exist, such as in unpackaged versions of the app or in locally packaged versions, it will use the hosted site instead. There is a sibling PR in the docs repository to build the embedded version of the app (strips out some external links, removes Algolia DocSearch, updates the baseUrl) https://github.com/wavetermdev/waveterm-docs/pull/46
2024-10-04 05:28:05 +02:00
with:
Move docsite to main repo (#1204) ## Summary We are moving our docsite to this repo for better coordination. ## What's changed? - The docsite codebase is now in docs/ - The docsite will replace storybook as the published GitHub Pages site for this repo - Storybook will now be hosted at https://docs.waveterm.dev/storybook - A new CI workflow will validate any changes to Storybook or the docsite - A combined CD workflow will build and deploy Storybook and the docsite as a single artifact - The Build Helper workflow will now build an embedded version of the docsite before building the app, ensuring the docsite version it has is always the latest
2024-11-06 19:45:21 +01:00
name: docsite
Embed static copy of docsite for help view (#949) This will take the latest artifact from the waveterm-docs repo and embed it in the app binary. When the help view is launched, it will be served from our backend. If the embedded copy doesn't exist, such as in unpackaged versions of the app or in locally packaged versions, it will use the hosted site instead. There is a sibling PR in the docs repository to build the embedded version of the app (strips out some external links, removes Algolia DocSearch, updates the baseUrl) https://github.com/wavetermdev/waveterm-docs/pull/46
2024-10-04 05:28:05 +02:00
path: ${{env.STATIC_DOCSITE_PATH}}
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
# Build and upload packages
Snap support (#1095) Adds Snap support, though I'm still waiting to hear back from the Snapcraft team about getting our package listed. closes #1092
2024-10-22 03:13:19 +02:00
- name: Build (Linux)
if: matrix.platform == 'linux'
run: task package
env:
USE_SYSTEM_FPM: true # Ensure that the installed version of FPM is used rather than the bundled one.
STATIC_DOCSITE_PATH: ${{env.STATIC_DOCSITE_PATH}}
SNAPCRAFT_BUILD_ENVIRONMENT: host
- name: Build (Darwin)
if: matrix.platform == 'darwin'
Setup the Build Helper pipeline (#116) Ports over the Build Helper pipeline from the old app. It will stage to a new S3 bucket for now. I haven't added the auto update yet.
2024-07-18 07:39:22 +02:00
run: task package
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
env:
Enable Linux ARM builds (#127) Adds support for building for Linux ARM targets using the new GitHub Linux ARM64 runners. Adds a new menu item to toggle the visibility of the menu bar on non-darwin targets,
2024-07-20 01:11:08 +02:00
USE_SYSTEM_FPM: true # Ensure that the installed version of FPM is used rather than the bundled one.
Update secrets to the new Apple Developer account creds (#384)
2024-09-17 08:10:04 +02:00
CSC_LINK: ${{ matrix.platform == 'darwin' && secrets.PROD_MACOS_CERTIFICATE_2}}
CSC_KEY_PASSWORD: ${{ matrix.platform == 'darwin' && secrets.PROD_MACOS_CERTIFICATE_PWD_2 }}
APPLE_ID: ${{ matrix.platform == 'darwin' && secrets.PROD_MACOS_NOTARIZATION_APPLE_ID_2 }}
APPLE_APP_SPECIFIC_PASSWORD: ${{ matrix.platform == 'darwin' && secrets.PROD_MACOS_NOTARIZATION_PWD_2 }}
APPLE_TEAM_ID: ${{ matrix.platform == 'darwin' && secrets.PROD_MACOS_NOTARIZATION_TEAM_ID_2 }}
Embed static copy of docsite for help view (#949) This will take the latest artifact from the waveterm-docs repo and embed it in the app binary. When the help view is launched, it will be served from our backend. If the embedded copy doesn't exist, such as in unpackaged versions of the app or in locally packaged versions, it will use the hosted site instead. There is a sibling PR in the docs repository to build the embedded version of the app (strips out some external links, removes Algolia DocSearch, updates the baseUrl) https://github.com/wavetermdev/waveterm-docs/pull/46
2024-10-04 05:28:05 +02:00
STATIC_DOCSITE_PATH: ${{env.STATIC_DOCSITE_PATH}}
Snap support (#1095) Adds Snap support, though I'm still waiting to hear back from the Snapcraft team about getting our package listed. closes #1092
2024-10-22 03:13:19 +02:00
- name: Build (Windows)
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
if: matrix.platform == 'windows'
run: task package
env:
USE_SYSTEM_FPM: true # Ensure that the installed version of FPM is used rather than the bundled one.
CSC_LINK: ${{ steps.variables.outputs.SM_CLIENT_CERT_FILE }}
CSC_KEY_PASSWORD: ${{ secrets.SM_CLIENT_CERT_PASSWORD }}
Embed static copy of docsite for help view (#949) This will take the latest artifact from the waveterm-docs repo and embed it in the app binary. When the help view is launched, it will be served from our backend. If the embedded copy doesn't exist, such as in unpackaged versions of the app or in locally packaged versions, it will use the hosted site instead. There is a sibling PR in the docs repository to build the embedded version of the app (strips out some external links, removes Algolia DocSearch, updates the baseUrl) https://github.com/wavetermdev/waveterm-docs/pull/46
2024-10-04 05:28:05 +02:00
STATIC_DOCSITE_PATH: ${{env.STATIC_DOCSITE_PATH}}
Set up Windows build pipeline (#292) This adds a new job to the Build Helper pipeline for building for Windows. This includes code signing via DigiCert. Right now, we can only build for x64 on Windows as wavesrv fails to build for arm64 in the default runner and the Windows ARM runner images are missing a bunch of tooling. This also adds new separated arm64 and x64 for macOS for those who don't want to use the universal binary. This also improves the general code quality of the Taskfile.yml and the build-helper.yml files.
2024-08-30 19:13:40 +02:00
shell: powershell # electron-builder's Windows code signing package has some compatibility issues with pwsh, so we need to use Windows Powershell
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
Remove release creation race in build helper (#1133) There was a race condition in the Build Helper where if multiple runners got to the "Create draft release" step at the same time, we could get duplicate releases created. Now, each of the build runners will upload the artifacts to the workflow artifact feed. Then, a single runner will create the draft release.
2024-10-25 03:42:48 +02:00
# Upload artifacts to the S3 staging and to the workflow output for the draft release job
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
- name: Upload to S3 staging
Attempt to fix chrome-sandbox permissions issue on Linux (#1089) Also allows for test runs of build-helper, which will not upload to staging
2024-10-21 21:52:13 +02:00
if: github.event_name != 'workflow_dispatch'
Add automated release flow (#394) ## New release workflow Build Helper will now automatically create a draft GitHub Release after it finishes its builds. It will upload a copy of the build artifacts to this release for easy access. When a version is ready to be published, edit the GitHub Release and publish it. This will trigger a workflow to publish the artifacts to our releases feed. ## Moved artifacts scripts to Taskfile The scripts formerly located at `scripts/artifacts` have been moved to the Taskfile. They can now be found at `artifacts:*`. ## Moved releases readme to `RELEASES.md` Updated the releases readme with step-by-step instructions and moved it from `scripts/artifacts` to `RELEASES.md` ## Created new AWS identities for artifact upload and publishing This narrows the scopes of the AWS identities used by the workflows to upload and publish artifacts. The Build Helper workflow now only has permission to put files into the artifacts bucket. The Publish Release workflow only has permission to get files from the artifacts bucket and put them into the releases bucket.
2024-09-18 21:29:47 +02:00
run: task artifacts:upload
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
env:
Add automated release flow (#394) ## New release workflow Build Helper will now automatically create a draft GitHub Release after it finishes its builds. It will upload a copy of the build artifacts to this release for easy access. When a version is ready to be published, edit the GitHub Release and publish it. This will trigger a workflow to publish the artifacts to our releases feed. ## Moved artifacts scripts to Taskfile The scripts formerly located at `scripts/artifacts` have been moved to the Taskfile. They can now be found at `artifacts:*`. ## Moved releases readme to `RELEASES.md` Updated the releases readme with step-by-step instructions and moved it from `scripts/artifacts` to `RELEASES.md` ## Created new AWS identities for artifact upload and publishing This narrows the scopes of the AWS identities used by the workflows to upload and publish artifacts. The Build Helper workflow now only has permission to put files into the artifacts bucket. The Publish Release workflow only has permission to get files from the artifacts bucket and put them into the releases bucket.
2024-09-18 21:29:47 +02:00
AWS_ACCESS_KEY_ID: "${{ secrets.ARTIFACTS_KEY_ID }}"
AWS_SECRET_ACCESS_KEY: "${{ secrets.ARTIFACTS_KEY_SECRET }}"
Set up electron-builder for new app (#113) Adds electron-builder, which we will use to package and distribute our application, same as in the existing app. Replaces explicit port assignments with dynamic ones, which are then stored into environment variables. Adds a ~/.w2-dev folder for use when running a dev build. The build-helper pipeline from the old repo is included here too, but it is not updated yet so it will fail. Also removes some redundant utility functions and cleans up some let vs. const usage. The packaging can be run using the `package:prod` and `package:dev` tasks. --------- Co-authored-by: sawka <mike.sawka@gmail.com>
2024-07-18 03:42:49 +02:00
AWS_DEFAULT_REGION: us-west-2
Remove release creation race in build helper (#1133) There was a race condition in the Build Helper where if multiple runners got to the "Create draft release" step at the same time, we could get duplicate releases created. Now, each of the build runners will upload the artifacts to the workflow artifact feed. Then, a single runner will create the draft release.
2024-10-25 03:42:48 +02:00
- name: Upload artifacts
uses: actions/upload-artifact@v4
with:
name: ${{ matrix.runner }}
path: make
create-release:
runs-on: ubuntu-latest
Move docsite to main repo (#1204) ## Summary We are moving our docsite to this repo for better coordination. ## What's changed? - The docsite codebase is now in docs/ - The docsite will replace storybook as the published GitHub Pages site for this repo - Storybook will now be hosted at https://docs.waveterm.dev/storybook - A new CI workflow will validate any changes to Storybook or the docsite - A combined CD workflow will build and deploy Storybook and the docsite as a single artifact - The Build Helper workflow will now build an embedded version of the docsite before building the app, ensuring the docsite version it has is always the latest
2024-11-06 19:45:21 +01:00
needs: build-app
fix builder 2 (#1150)
2024-10-26 21:18:27 +02:00
permissions:
contents: write
Remove release creation race in build helper (#1133) There was a race condition in the Build Helper where if multiple runners got to the "Create draft release" step at the same time, we could get duplicate releases created. Now, each of the build runners will upload the artifacts to the workflow artifact feed. Then, a single runner will create the draft release.
2024-10-25 03:42:48 +02:00
if: ${{ github.event_name != 'workflow_dispatch' }}
steps:
- name: Download artifacts
uses: actions/download-artifact@v4
with:
path: make
merge-multiple: true
Add automated release flow (#394) ## New release workflow Build Helper will now automatically create a draft GitHub Release after it finishes its builds. It will upload a copy of the build artifacts to this release for easy access. When a version is ready to be published, edit the GitHub Release and publish it. This will trigger a workflow to publish the artifacts to our releases feed. ## Moved artifacts scripts to Taskfile The scripts formerly located at `scripts/artifacts` have been moved to the Taskfile. They can now be found at `artifacts:*`. ## Moved releases readme to `RELEASES.md` Updated the releases readme with step-by-step instructions and moved it from `scripts/artifacts` to `RELEASES.md` ## Created new AWS identities for artifact upload and publishing This narrows the scopes of the AWS identities used by the workflows to upload and publish artifacts. The Build Helper workflow now only has permission to put files into the artifacts bucket. The Publish Release workflow only has permission to get files from the artifacts bucket and put them into the releases bucket.
2024-09-18 21:29:47 +02:00
- name: Create draft release
uses: softprops/action-gh-release@v2
with:
prerelease: ${{ contains(github.ref_name, '-beta') }}
name: Wave Terminal ${{ github.ref_name }} Release
generate_release_notes: true
draft: true
files: |
make/*.zip
make/*.dmg
make/*.exe
make/*.msi
make/*.rpm
make/*.deb
make/*.pacman
make/*.snap
make/*.flatpak
make/*.AppImage
Reference in New Issue Copy Permalink