actions
actions copied to clipboard
haskell
Doctest doesn't work if ghcup not used
When running doctest in Github Actions, if GHC is not installed via ghcup (for example it was already installed in the virtual environment) then the doctest fails in this manner:
doctest: /home/runner/.ghcup/ghc/8.10.3/bin/ghc-8.10.3: getPermissions:getFileStatus: does not exist (No such file or directory)
https://github.com/haskell-works/hw-aeson/pull/46/checks?check_run_id=1780850470
For some reason doctest expects that ghc is found under ghcup, when it is actually elsewhere.
Out of curiosity, what does the $PATH and contents of the .ghc.environment.x86_64-linux-8.10.3 file look like? This is a new one for me...
I don't have a good understanding of what the Haskell stuff for Github Actions actually does to set the environment up (but I suspect I'm going to have to learn it quite soon) - does it use ghcup? I am guessing there are two GHCs in play and doctest is getting confused about which one to use.
I see from the log that the build is downloading a large chunk of pre-built packages into .cabal. This might be it: doctest uses ghc-paths to know where to find GHC, which does some build-time magic. If the cached pre-built packages have GHC living somewhere else to where GHC lives on the builder, I wouldn't be surprised if that causes problems like this - though I am slightly surprised that this issue's only turning up now, because this sort of pattern isn't uncommon.
Thanks to a hint from quasicomputational, my best guess is this:
- github actions uses hvr's PPA on linux, falling back to ghcup if it didn't work.
- This line
-rwxr-xr-x 1 runner docker 59842504 Sep 29in the logs suggests that the cache hit is from approximately september 29? But either way, there was a period in time where the runners had not been updated to use the latest version of hvr's PPA, but ghcup was using GHC 8.10.3, so it was possible to install GHC 8.10.3 through ghcup before the PPA - This pipeline was ran during that time and thus had cached artifacts that were built with ghcup's GHC, and then later had cached artifacts built with the PPA's GHC
- Somehow this broke things??
So it requires a somewhat ridiculous chain of events, but it's not impossible. If that's the case, deleting the cache should fix the issue. Unfortunately I haven't the slightest idea how one might fix this except somehow by possibly either changing the caching strategy of cabal-cache, or by having doctests use alternative methods of finding GHC?
Right. If the theory's correct, this is really the collision of two issues:
doctestis not friendly to cross-compilation. I think that this might be for reasons, but I've forgotten what they were. I'll open an aspirational issue about that, but it might never get resolved.- The caching strategy is fragile for packages that don't cross-compile well. This looks more tractable in practice: just excluding
ghc-pathsand all its dependencies from the cache could be a significant improvement.
I'm keen on package maintainers avoiding things that make for non-relocatable cabal store packages where-ever possible.
It seems it is not very uncommon. I have hit the same issue: https://github.com/composewell/streamly/pull/1100/checks?check_run_id=2819329899 . I reached the same conclusion that it might be coming from the cache, tried bumping the cache version, but it did not help. I have to confirm that though, maybe the cache somehow did not get cleared.
It worked with clearing the cache too, earlier I made a mistake so the cache was not cleared.
Possibly related workaround: https://github.com/haskell-servant/servant/pull/1409/commits/164bfe96a9d50a56fe6df2fffb956988efe448fe
The ghc-paths package provides paths to GHC's package database and ghc itself. You can't compile ghc-paths with a ghc from one place and then later use it with a ghc from an other place (place == path of the ghc executable). If you do that, you are on your own. That's not doctest specific.
