On CI

John Ericson john.ericson at obsidian.systems
Fri Feb 19 03:18:38 UTC 2021


I am also wary of us to deferring checking whole platforms and what not. 
I think that's just kicking the can down the road, and will result in 
more variance and uncertainty. It might be alright for those authoring 
PRs, but it will make Ben's job keeping the system running even more 
grueling.

Before getting into these complex trade-offs, I think we should focus on 
the cornerstone issue that CI isn't incremental.

 1. Building and testing happen together. When tests failure spuriously,
    we also have to rebuild GHC in addition to re-running the tests.
    That's pure waste. https://gitlab.haskell.org/ghc/ghc/-/issues/13897
    tracks this more or less.
 2. We don't cache between jobs. Shake and Make do not enforce
    dependency soundness, nor cache-correctness when the build plan
    itself changes, and this had made this hard/impossible to do safely.
    Naively this only helps with stage 1 and not stage 2, but if we have
    separate stage 1 and --freeze1 stage 2 builds, both can be
    incremental. Yes, this is also lossy, but I only see it leading to
    false failures not false acceptances (if we can also test the stage
    1 one), so I consider it safe. MRs that only work with a slow full
    build because ABI can so indicate.

The second, main part is quite hard to tackle, but I strongly believe 
incrementality is what we need most, and what we should remain focused on.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210218/e70f1525/attachment.html>


More information about the ghc-devs mailing list