Reduce CI turnaround times

[hasufell]

At the moment the biggest bottleneck is mac x86_64 with:

• ~ 2 hours of build time (including ghcjs)
• ~ 1 hour of testing

Windows follows with ~2 hours.

Possible ideas to reduce:

• parallelize builds better?
• parallelize tests (e.g. into 3 parts and run them on separate runners)
• cache parts of the build (cabal? stage1? libraries?)
• reduce dependencies of stage1 (or use MicroHaskell?)
• stronger (or self hosted) runners

[angerman]

1. For reducing dependencies of stage1 we have minimal stage1 #118 (WIP).
2. I think we can disable cross compilers on x86_64-darwin. Building them on aarch64-darwin is probably good enough for general CI. For realease builds we'd want to build them of course.
3. Yes, cabal (the build system) is explicitly not part of building GHC. It is right now while we try to make it work, but we should be moving this out soon; and rely on only static pre-build cabals.
4. paralleization is also something we do want to improve. As well as general ghc build/compile times.

[hasufell]

For realease builds we'd want to build them of course.

I have strong opinions on this. I think we should not end up doing similar shenanigans like GHC upstream where some part of CI runs on every PR, then you have a "full CI" label and possibly yet another situation for release builds.

Every CI run should effectively be a release build. We can structure CI in a way that we see failures early and abort early to save resources.

E.g. I just realized... that we don't really have to wait for the ghcjs build before we can execute tests. We can fork off two jobs after stage2 is done:

• test stage2
• build stage3

[angerman]

I really think x86_64-darwin is in the way out. I also think that most of the coverage for x86_64-darwin is given by aarch64-darwin. Except for a few corner cases (link that link stuff), they should be identical.