Open gelisam opened 2 years ago
The CI / oldest
configuration fails with:
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-unknown-linux):
Prelude.chr: bad argument: 2583691267
This is presumably https://gitlab.haskell.org/ghc/ghc/-/issues/19452, which in turn means CI is caching files generated from one version of ghc and regenerating them when building with another version of ghc. But that doesn't make sense, because
CI / oldest
and CI / stable
use a different cache keyCI / stable
which is using a newer version of ghc, not CI / oldest
Hmm, what else could explain this error message?
Same error without the CI cache, so it's indeed something else. I can reproduce locally with stack --stack-yaml=oldest-supported-lts.yaml test
; I guess we need an older version of stack to build with older versions of ghc?
I get the same result with both the newest (stack-2.7.5) and oldest (stack-2.5.1) versions of stack supported by ghcup. ghcup only started installing stack relatively recently, so maybe I need to pick an even older version; or maybe the problem is not the version of stack at all. Hard to tell, with such an obscure error message!
Did the version of stack change?
I pretty sure I can build my projects with all ghc-8.x using stack-2.7 though.
Sounds plausible! We do not specify the stack-version parameter, so the haskell/actions/setup@v1
action defaults to whatever the action considers the latest. It's possible that the action changed which version that is during the last 4 months (CI last ran then and failed, but this particular test succeeded).
Ya, I am not sure what is going on: I see it is using Ubuntu 20.04: unfortunately older CI logs seem to have been already gc'ed...
I have definitely run into problems in the past here with ghc 7.10: ghc-8.0 is already getting a bit old I suppose. How about bumping oldest to 8.2 for now? Does that work?
Experimenting further, stack --stack-yaml=oldest-supported-lts.yaml test
works for me after deleting ~/.stack
(and installing happy
using stack --stack-yaml=stack.yaml install happy
as in the CI script). So I do think caching is involved after all. But how is that possible when I've deleted the actions/cache@v2
block? Could haskell/actions/setup@v1
be doing its own caching behind the scenes?
The haskell/actions/setup@v1
project is currently working on adding their own caching behind the scenes, so I can safely conclude that no, the current version of haskell/actions/setup@v1
is not already doing its own caching :)
What else could it be then?
According to https://github.com/commercialhaskell/stackage/issues/6486#issuecomment-1073120672, haskell-awk has been dropped from nightly because it doesn't compile with ghc-9.2.2, so we need to support that version in order to get back into stackage.