Move Linux, Windows and MacOS CI/CD to Github Actions

[monacoremo]

Now that Travis and CircleCI impose capacity limits, it's probably easiest for us to run everything on Github Actions.

Progress on feature parity with legacy CI

• Build static Linux executable and Docker image with Nix
• Build MacOS executable with Stack
• Build Windows executable with Stack
• Build FreeBSD executable - Options:
  • keep CirrusCI for now - how to best get binary into release?
    • went for this: Configured CirrusCi to save the build as an artifact and wrote a script to get that artifact in the release job
  • use a hack and run a FreeBSD VM on a Github Actions MacOS runner
    • decided against this, too hacky. The freebsd-vm uses a pre-cooked vm image that I can't jnspect
• Run linter & style check
• Run tests with Nix
  • Colors in output - GitHub Actions limitation, does not provide a TTY; hack from Not a tty actions/runner#241 (comment) shell: 'script -q -e -c "bash --noprofile --norc -eo pipefail {0}"' - used only for the Nix tests for now
  • Run all tests, even if one fails
  • Cache cabal - not needed, quick enough (< 5 min)
• Build and run tests with Stack on Linux
  • Run memory tests - don't think this is needed as we run those with Nix
• Upload coverage
• Release nightlies - might not be needed as we can publish artifacts with each CI run? tbd
  • replaced by:
    • Bleeding edge available through artifacts saved for each check run
    • Pre-releases (e.g. 9.0.0-a1, -b4 etc. for alphas and betas) automatically released and pushed to Docker Hub when tagged
• Actual releases

Extra

• Run tests on MacOS
• Release only if builds for all platforms succeeded
• No secrets required on CirrusCI
• Added a simple release script to tag and trigger a release - just set the right version in postgrest.cabal, commit and run .github/release
• Switched the FreeBSD build from cabal-install to Stack for consistency (same GHC, libraries etc. as all other builds)

Not for this PR:

• Build Linux Arm executable - same as FreeBSD or with self-hosted runner

Tasks before merge

• Set Codecov token
  • Probably not needed as Wolfgang pointed out, let's remove it
• Set CACHIX_AUTH_TOKEN secret
• Set DOCKER_PASS secret (is postgrest-bot the right user name?
• Disable CircleCI on this repo
• Disable Travis on this repo
• Disable Appveyor on this repo

[monacoremo]

@steve-chavez Do we need to enable Github Actions in the settings?

[steve-chavez]

Do we need to enable Github Actions in the settings?

Just checked, they're enabled.

Upload coverage - requires token

Will set this.

[monacoremo]

Do we need to enable Github Actions in the settings?

Just checked, they're enabled.

Hm, it doesn't trigger for this PR somehow.. Are the settings set like this?

• Actions permissions: Allow all actions?
• Fork pull request workflows from outside collaborators: Require approval for first-time contributors?
• Workflow permissions: Read repository contents permission would be preferrable

[steve-chavez]

Hm, it doesn't trigger for this PR somehow.. Are the settings set like this?

Yes, screenshot:

[steve-chavez]

Hm, still not triggering I see. Maybe it's because of the draft PR?

[monacoremo]

Ah, here we go - apparently had to disable GH Actions in my fork. Thank you @steve-chavez !

[monacoremo]

First successful run:

Note: With the hot cache we have now the Stack builds are just 1-3 minutes.

We now have executable for each OS available as artifacts for each push, see the list at the bottom. I think this could supercede our nightly setup - WDYT @steve-chavez ? Only thing to potentially change would be to patch the version in postgrest.cabal if there is no tag.

[steve-chavez]

I think this could supercede our nightly setup - WDYT @steve-chavez ? Only thing to potentially change would be to patch the version in postgrest.cabal if there is no tag.

Hm, I do see there's some overlap with how we do the nightlies. But having all of them on the same release page feels more convenient, each nightly can also point to its changelog. How would we instruct users to use nightlies with this new way?

[monacoremo]

Hm, I do see there's some overlap with how we do the nightlies. But having all of them on the same release page feels more convenient, each nightly can also point to its changelog. How would we instruct users to use nightlies with this new way?

Let me try!

1. If you want to test the latest unreleased features, go to , pick a recent green build and download the artifact for your platform. To see what changed, follow the linked PR/commit and look at the Changelog
2. If you want to test a specific unreleased change, klick the green CI indicator on the respective PR/commit, go to the CI action and download the artifact for your platform

Case (1) is a different place to look at, but I don't think it would be too much for powerusers that want to test unreleased features. And we aim to release more often anyway :-)

Case (2) is not even possible right now

[wolfgangwalther]

Upload coverage - requires token

Will set this.

I don't think we need a token here. At the codecov-action repo it says:

For public repositories, no token is needed

[monacoremo]

I don't think we need a token here. At the codecov-action repo it says:

For public repositories, no token is needed

Ah, good catch - will try without

[monacoremo]

Apparently with_tmp_db was portable all along! Spec tests now also run on MacOS 🎉

[steve-chavez]

If you want to test the latest unreleased features, go to image, pick a recent green build and download the artifact for your platform. To see what changed, follow the linked PR/commit and look at the Changelog

Ah, I forgot. We have to consider docker as well, we were also releasing nightlies there.

[monacoremo]

@steve-chavez This new setup now works pretty well!

With hot caches, a full CI run takes 5-10 minutes, including all tests as well as the builds for Linux, Windows, MacOS and FreeBSD.

Build artifacts for all platforms are available for every single commit, also from pull requests. I believe this covers most of the need for the 'nightly' release (which was quite inconsistent so far). To replace it, my suggestion is:

• For bleeding edge builds (e.g. testing whether a commit fixed an issue), direct users to the respective CI build. The Docker image can be imported with docker load -i ...
• For intermittent updates, use pre-releases such as '8.0.1-a1' or '9.0.0-b2' etc.) - these get released on GitHub as pre-releases and tagged on Docker Hub, leaving 'latest' untouched
• For proper releases, do full releases on GitHub and also push to 'latest' on Docker Hub

The workflow enforces that the tagged version corresponds to the version in postgrest.cabal before releasing. This way, pre-releases will have a proper version, without the approach of patching the cabal file, which breaks caches and is a bit messy imo)

WDYT?

[steve-chavez]

@monacoremo Looks amazing! Great work! 💯 🥇

for the 'nightly' release (which was quite inconsistent so far).
without the approach of patching the cabal file, which breaks caches and is a bit messy imo)

True, the nightlies were more of a hack. Let's go ahead with your approach 👍

[monacoremo]

@monacoremo Looks amazing! Great work! 💯 🥇

Thank you, glad to hear! :-)

I've tested the release steps on my https://github.com/monacoremo/postgrest fork, both pre-releases and full releases.

@steve-chavez I've noted the last todos that need to be completed by you as the repo owner above:

• Set Codecov token
  • Probably not needed as Wolfgang pointed out, let's remove it
• Set CACHIX_AUTH_TOKEN secret
• Set DOCKER_PASS secret (is postgrest-bot the right user name?
• Disable CircleCI on this repo
• Disable Travis on this repo
• Disable Appveyor on this repo

Would you be able to make those changes and then we merge?

[steve-chavez]

Would you be able to make those changes and then we merge?

@monacoremo Sure. Done!

Also, I've revoked the secrets and Github apps that Appveyor and Travis had(CircleCI still has an installed app on the org because we use it on postgrest-docs).

is postgrest-bot the right user name?

I don't have the postgrest-bot creds anymore(it was created using begriffs' account), so it should be changed to my username "stevechavez". I've confirmed it works, I used it for v8.0.

[steve-chavez]

@monacoremo Do you know what's the state of building the static binary with Nix on ARM? It didn't work last time we tried.

Ideally we'd build the ARM binary on Github Actions. Currently I build the ARM binary manually for Ubuntu.

[monacoremo]

I think that's going to be quite tricky - but let's try it! Do you have a machine that we can use for testing @steve-chavez ?

On the Nix side, I dont think that https://github.com/nh2/static-haskell-nix that we rely on actively tracks whether ARM-builds succeed. But it could work in principle and we could be lucky, let's see! A full alternative would be to use https://input-output-hk.github.io/haskell.nix/tutorials/cross-compilation/ instead of the standard Nix setup, but that would be a major undertaking.

On the GitHub Actions side, I don't think there is an ARM runner right now... We would need to host an external runner.

[steve-chavez]

Do you have a machine that we can use for testing @steve-chavez ?

I do! I use a t4g.large on AWS to build the Ubuntu binary. I'll grant you access and share you the details through email 📧