Commit Graph

7 Commits (89ab0422035d7c43ac6f0bbe546d9ebdedc2a268)

Author SHA1 Message Date
Maximilian Federle eb17248bd5 CI: Replace edge releases with links to artifacts
Re-creating the edge release for every push
to master creates many superfluous release notifications.

Stop creating those releases and provide users with direct
links to the workflow artifacts instead via the
nightly.link GitHub app (https://github.com/apps/nightly-link).

Fixes #1103
2021-10-29 16:47:38 -04:00
Maximilian Federle 6bc63e92b0 snap: Fetch tags for snap builds in CI & mention stable channel in README
The snaps use git describe to determine
their grade (stable/devel). Fetch the tags to
make this possible.

Point users to the official release in the stable channel in README.md.
2021-09-03 18:44:21 -04:00
Maximilian Federle 0e0b0252e2 CI: Never skip cancel_previous_runs
The if condition was nonsensical and did not serve any
practical purpose; removing it allows the succeeding jobs
to run in any case without additional code.
2021-04-18 05:48:36 -04:00
Maximilian Federle f4ad82055e CI: Support cancelling, update actions & prevent draft releases
Allow the workflow to be cancelled without running all remaining jobs.
On invocation of the workflow, cancel concurrent runs of older commits
automatically.

Replace unmaintained release action with recommended alternative.

After much testing, I found that the problem of releases
being created as draft releases can be traced to a
consistency issue/race condition on GitHub's side.
Prevent this by inserting a generous delay between deleting and
re-creating the edge release.
2021-04-09 17:43:31 -04:00
Koen Schmeets 8105699d5e Add apple arm64 support 2021-04-04 11:40:10 -04:00
Maximilian Federle d8816863d0 CI: Lock qemu version to known working 2021-03-30 08:14:46 -04:00
Maximilian Federle 5fa23189d9
CI: Replace Travis with GitHub Actions (#824)
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/824

Fixes #807
2020-12-08 18:19:33 +01:00