[GHC DevOps Group] State of CI

[Simon Marlow]

On 6 June 2018 at 09:21, Boespflug, Mathieu <m at tweag.io> wrote:

> * As seen here, https://circleci.com/gh/ghc/ghc, master is currently
> red on everything but x86_64-linux (sans LLVM, sans Hadrian).
> * This means that starting from a stock Debian Jessie, we can't get
> validate to pass on stock virtualized infrastrure (except for one).
> * So the first order of business is to get ghc HEAD to a sufficient
> level of quality that validate passes everywhere and so that CI
> becomes useful.
>

Exactly. Getting the tree green and keeping it green should definitely be
the highest priority.

I should point out for those who weren't aware, however, that CircleCI
raised the bar for "green" from what we had previously been using, because
the CircleCI build adds profiling and runs tests in a lot more ways than a
plain validate does. It's taken quite a while to catch up and clean up the
broken things that were preventing the CircleCI build from being clean. (of
course this is all work that we would want to do anyway, I'm just
mentioning it by way of explanation for why the CircleCI builds weren't
clean earlier and are still not clean on many platforms)


> * None of this work is GitHub specific. Nor all that CircleCI or
> Appveyor specific for that matter (work is currently focused on
> improving the test suite).
> * Our GitHub lock-in factor is currently low to pretty much absent,
> and would remain low even if the review workflow becomes more
> systematically GitHub centric (it already is for some small
> contributions).
> * That's because tickets remain on Trac, and the code along with the
> entirety of its history remains in a standard Git repository, GitHub
> or not. Also because GitHub is not a CI provider, those providers we
> do use integrate with other code hosting solutions (e.g. Appveyor with
> GitLab), and the surface area of CI provider-specific code is small.
>

We should keep in mind, though, is that past code reviews is valuable
content that we can't discard, nor can we easily migrate it to a different
code review platform. At this point we have nearly 5K diffs on Phabricator,
many of which have non-trivial code-review trails, and these are
cross-referenced from Trac, emails, and other places. Even if we moved to
github, we would want to keep Phabricator running so that we have access to
this content, and people will experience friction though havng to deal with
another system.

To me, the friction caused by the transition and the inability to do a
clean move is more worrying than the missing code review functionality on
github.

Cheers
Simon


> Now, this isn't to say that other options (e.g. GitLab or Bitbucket,
> for code review and/or for code hosting and/or for CI) aren't worth
> considering medium term. It's that I see no reason to stall first
> getting to a stable situation where CI is green on all "Tier 1"
> platforms on all types of hardware, nor to fear accepting even more
> contributions from GitHub users.
>
> Best,
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20180606/d67c9732/attachment-0001.html>