Add .github/workflows/ci.yaml for GitHub Actions

[mitchellwrosen]

Overview

This PR adds a .github/workflows/ci.yaml file for GitHub actions. I tried to make it perform roughly the same actions as the Travis CI config (build and run tests with both runtimes, then cache stuff).

Interesting/controversial decisions

I cached the local packages' build artifacts in .stack-work their directories, in addition to ~/.stack, which caches dependencies. The intention here is for CI to be similar in speed to locally editing a file and rebuilding - presumably not every local module will need to be recompiled.

However, there may be some downsides to caching .stack-work that I haven't thought of, and I didn't measure whether caching it actually produced a measurable speedup.

Loose ends

Only an Ubuntu build is configured at the moment, but macOS shouldn't be too hard to add. The main reason I didn't add it in this first pass is I had to download stack manually as part of the build, because the official setup-haskell action is broken right now (it uses a deprecated mechanism for setting environment variables). So, the build explicitly downloads a linux flavor of stack, but that could switch on the runner's OS instead.

[aryairani]

Re: caching, I'm scared of the situation where CI is succeeding but a clean build fails, because it actually depends on something old in the cache. I'd rather have CI be slower (within reason) but more reproducible. Thoughts?

[mitchellwrosen]

@aryairani Makes sense to me, but just to clarify, this would be defending against a potential bug in stack. Is that correct? (And by "within reason" do you mean we should still cache ~/.stack but not .stack-work?)

[pchiusano]

Definitely keep at least ~/.stack otherwise you're rebuilding all your dependencies every time, right? And builds would take like 2 hours. :)

And I'd also vote to keep ~/.stack-work except for releases - for releases let's do a clean build. I'm thinking of the day-to-day quality of life improvement of having near instant instant CI results vs the theoretical possibility of a stack caching bug.

I can't recall the last time I've had to do a stack clean honestly... so while in principle there could be some bugs with stack's caching, I don't think we should be worrying about that too much for day-to-day work merging to trunk.

[aryairani]

Would it be possible to have both of these?

• a quick, caching CI task that we use for development branches & PRs
• a long CI task that builds everything from scratch — simulating building as a first-time contributor, or building on a new machine. This sanity-checks that newer minor releases of dependencies are still compatible, new releases of stack, etc. But this one wouldn't have to complete before merging a PR, for example. Basically making sure that anyone who follows the CI steps on their own machine can build the project.

[aryairani]

@mitchellwrosen I'd say if you can add the mac build, then let's merge it — we want to avoid surprises like #1616. The travis.yaml should show how to set up tools for a mac build; or is it missing something?

I'd like to run the build on multiple linuxes, multiple macoses, and maybe even some windows. Do you know if it's possible to designate certain images to be required successes and others to be optional successes?

[pchiusano]

Okay, we're going to merge this and delete the Travis build since Travis has become unusable with hours long wait times and lots of spurious failures, but @mitchellwrosen can you work on adding the macos build at least?

[pchiusano]

Thanks for looking into this @mitchellwrosen !

[mitchellwrosen]

@pchiusano, yup, it's on my list of things to do today in fact!