Improve CI setup about asterius HOT 6 CLOSED

I'd like a clearer statement of the requirements. Implicit in the current description are:

• GHC is an evolving target, so bindists need to be regenerated periodically.
• You want to regenerate a bindist every few hours independently from Asterius CI.
• You want Asterius CI to pull whatever latest GHC was generated and use that during CI.

If so, then these sound like the wrong requirements to me.

• Precisely because GHC is a moving target, we should not target whatever is the latest GHC during CI.
• We should carefully track which GHC we use via a submodule reference in the asterius repo.
• The GHC submodule ref should not be updated automatically. It should be updated manually at controlled points in the asterius release cycle. Otherwise it'll be very hard to track the source of regressions.
• There should be only one CI system: the one for asterius. Having two CI systems is inevitably going to create all manner of races (e.g concurrent access to S3 bucket while being written by other CI system).
• GHC should be (re)built as part of CI.
• Use caching to avoid GHC being rebuilt each time. We want the following property: CI rebuilds GHC if and only if the ghc submodule ref was updated.

from asterius.

Further nice-to-have requirements (may or may not be workable):

• asterius should remain forkable. If CI relies on custom infra, then it's no longer forkable (any forker would need to replicate this infra themselves). This implies that CircleCI cache better than an S3 bucket that would be world readable but only writable from Tweag workspace.

from asterius.

@mboes I'd like to clarify a bit. I decided to base asterius on ghc head and follow upstream changes, because that was one of a pain spot when using ghcjs in the past (having several branches for different ghc releases, requiring extra effort to make it work once a new release is out, etc). That's the reason for routinely bumping ghc revisions, because for small breaking changes in ghc master (which happens a lot!) it's relatively easy to follow, but for point releases it will be a lot of work.

Furthermore, right now it's already deterministic: every revision of asterius already pins with one exact commit of ghc, so even if a regression is introduced it won't be much of a problem to bisect and track the breaking commit.

Also, the current CI setup and the new one @mrkkrp is working on both don't trigger a new build for ghc with every asterius commit.

I'm okay with introducing a ghc tree as submodule and using that, but automatic (or at least, semi-automatic) bumping of ghc revisions is not nonsense. I hope I've explained the rationale.

from asterius.

To be clear, I'm not arguing to only use GHC releases. Using a commit from GHC HEAD is fine, so long as we're not automatically switching to whatever is the latest commit. This is no different than for any other project dependency. Dependencies need to be vetted, and updates to dependencies need to be vetted too.

Also, the current CI setup and the new one @mrkkrp is working on both don't trigger a new build for ghc with every asterius commit.

I think they should (but thanks to caching this won't be noticeable).

from asterius.

Opened #7 for CircleCI part.

from asterius.

We are building ghc bindists on separate branches then using them for CI in master and other wip-* branches. The advantage of building bindists instead of utilizing CI caches is improved end-user experience: people do not need to set up a building environment on their end, rather they'll just use a plain stack build and it mostly works out of the box.

from asterius.