Skip to content

Instantly share code, notes, and snippets.

@hasufell

hasufell/github.md

Last active October 18, 2022 12:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hasufell/c26f6bb1897bf98ef73a48bb1cf9a9c4 to your computer and use it in GitHub Desktop.
Save hasufell/c26f6bb1897bf98ef73a48bb1cf9a9c4 to your computer and use it in GitHub Desktop.
Download ZIP
Migrating tooling to github / providing github action runners to Haskell infrastructure
Raw
github.md

Migrating tooling to github / providing github action runners to Haskell infrastructure

Current state

  1. GHCup relies on Gitlab CI for testing and releases
  2. GHCup maintainers also use Gitlab CI to build darwin M1 stack binaries
  3. HLS and Cabal rely on Gitlab CI for releases only
  4. projects like bytestring rely on very slow emulation on github actions or other semi-private runners

The problem

  1. GHC Gitlab is focussed on providing working GHC binaries and environment for GHC developers. That makes other projects or less popular Systems (like FreeBSD) second class citizens. The current state of priorities was communicated here
  2. All runners on GHC Gitlab are custom and are often maintained by different parties. Getting support for broken runners is not always easy. In fact, I have a more direct line to Github staff (who are old Gentoo dev colleagues) than to GHC gitlab devops or runner maintainers. On Github, we would only maintain a subset of runners ourselves (e.g. darwin M1) instead of all of them.
  3. Maintaining two sets of CI configurations for HLS and Cabal is not only a maintenance burden, but also means that these projects don't regularly test their PRs and changes against ALL architectures, but only do so at release time (which may be too late). All those projects have communicated that they don't want to migrate fully to Gitlab last I asked (and actually proposed this).
  4. Ideally, all core tooling and core libraries should have access to all relevant architectures that GHC supports... on Github actions.

The solution

  1. migrate GHCup fully to Github
  2. migrate release CI of HLS and Cabal to Github
  3. buy our own runners (for e.g. darwin M1) with Opencollective money from GHCup and HLS and with help from HF funding and maintain them across our teams
    • darwin M1 prolly at 150$ per month per box (e.g. Macstadium)
    • AWS instances (FreeBSD and aarch64 Linux) for 730 hours (one month) somewhere around 50-150$ per box, depending on instance
    • initial cost may be 500-1000$ per month for a kickstart

HF has indicated (but not promised) that they may help with resources or funding of this solution.

Side effects

  • may reduce runner pressure and load on Gitlab CI, freeing up resources for GHC development
  • will reduce pressure on devops, because CI issues affect less projects

Remarks

Matthew's concerns on environment and reproducibility

Matthew was concernd about not using gitlab environments (probably the ci docker images) to match the environment where GHC is built.

Note from Julian: However, we don't do that in HLS CI anyway, at the moment, only partly.

Zubin remarked we can switch CI to gitlab without switching source control

HLS and Cabal could theoretically use gitlab CI exclusively for both testing and releases and then have hooks and integration with github.

Note from Julian: that would only fix problem 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment