Travis's move away from providing unlimited build time to OSS and its
inferior developer experience are the reason for this change.
The workflows are simple and straightforward, and the build scripts
are mostly 1:1 the same we used on Travis. This avoids vendor lock-in
as much as possible in case we need to move somewhere else in the future.
We introduce two workflows:
1. CD (cd.yml)
Runs on: Commits to master, GitHub releases.
Does: Run tests, build release assets, update GitHub edge release or
release to developer created GitHub release. Builds & uploads snaps to
the Snap Store.
2. Test (test.yml)
Runs on: Every commit except those on master and v* tagged ones.
I.e. PRs and other branches.
Does: Run tests only.
Creating a release is now an explicit operation. On the Travis workflow,
pushing a tag that begins with "v" will lead to the automatic creation of
an associated GitHub release.
On GHA, creating a GitHub release by hand will trigger the CD-workflow
to build & upload the release assets.
Other differences to Travis:
- Windows builds on Visual Studio 16 2019 instead of Visual Studio 15 2017.
- Snap builds run in docker containers, not directly on the build host.
- Snap arm64 builds on amd64 via QEMU user emulation.
This is slower than what Travis gave us and should be changed when/if
GHA offers ARM64 build runners.
- GHA retains build artifacts for 90 days by default.
Required secrets:
- MACOS_CERTIFICATE_PASSWORD
- MACOS_CERTIFICATE_P12
- MACOS_APPSTORE_APP_PASSWORD
- MACOS_APPSTORE_USERNAME
- MACOS_DEVELOPER_ID
- SNAPSTORE_LOGIN
Discussion: https://github.com/solvespace/solvespace/issues/807
PR: https://github.com/solvespace/solvespace/pull/824Fixes#807
Maximilian Federle