Conversation
For tests, we really don't need to do much more than build the compiler and run the tests --- Cabal shenanigans shouldn't be really necessary, so we can just use Stack here, which should handle caching much better. The `builtin-arrays' builds are currently broken, except on Dargent branches --- when those are merged, these builds should be flipped back to required. * Cogent ext2fs builds on Travis. * BilbyFs doesn't currently compile; it really should...
While we're here, bump resolvers.
zilinc
left a comment
zilinc
left a comment
There was a problem hiding this comment.
One general concern is that, we claim we support ... versions of GHC (in cogent.cabal) whereas using stack, many of the claimed versions are not tested. Shall we drop the untested versions? Apart from that, I'm happy with all aspects of this change.
|
|
||
| extra-package-dbs: [] | ||
| extra-deps: | ||
| - sbv-7.12 # for the `array' branches |
There was a problem hiding this comment.
A question: on my branch, I use sbv > 8. Which version of sbv can I have via extra-deps?
There was a problem hiding this comment.
This is only to get the pins right given the current builtin-arrays code. In theory, you can have whatever version you like. I believe sbv-8.x works fine, although I vaguely recall running into issues with crackNum, a sbv dependency, on GHC 8.2; I'd need to test that again to check, and I'd want to make sure stuff still compiles happily in general anyway.
|
@zilinc wrote:
We could test those. However, I believe it's more valuable to instead test the flag combinations (or to instead turn on more flags by default). e.g., how do recursive-types interact with Docgent or the Haskell backend? This would expand our test matrix massively, unfortunately. I propose we strip back supported versions to the latest on each of the GHC-x.y branches, unless there's good reason to maintain testing against the point-releases. Given we're also looking at GHC-8.8 support, perhaps this makes a good opportunity to also drop support for 8.2.x? |
jashank
force-pushed
the
jashank/2020/02/27/zoom-zoom-ci
branch
from
bda0cd5 to
9ee1060
Compare
* With +docgent, we use Pandoc, which won't Haddock in Stack. * With +haskell-backend, we get the haskell-lexer, which segfaults Haddock.
jashank
force-pushed
the
jashank/2020/02/27/zoom-zoom-ci
branch
from
9ee1060 to
329cd7e
Compare
2 participants
Currently, CI cycle times are awful --- and really variable. The longest recent build I've seen is 9h45m21s, and most builds hover between 5h and 9h. Occasionally, the caches will smile on us and bestow a 45-minute-or-less cycle time, and even that's pretty miraculous.
After lots of experimenting, cajoling, and swearing, I think I've got CI cycle times down to about a quarter-hour or less, consistently.
Along the way, I've flensed out a lot of complexity in the build --- for tests, we really don't need to do much more than build the compiler and run the tests --- Cabal shenanigans shouldn't be really necessary, so we can just use Stack here, which is much more amenable to caching.
builtin-arrays-enabled builds are currently broken, except on Dargent branches --- when those are merged, these builds should be flipped back to required.A build that went OK, I guess:
Some builds that did not go well: