Restore consistency in ci using alpine in all workflows

[jneira]

• As commented here: Distribute Alpine binaries #2461 (comment)
• Sadly my pessimistic concern has come true and we hit two errors in the alpine build for the release that could have been caught before if the regular test workflow uses the same env to make the build (now uses raw ubuntu):
  • First the inclusion of a new dependency using integer-gmp without flag to switch break the build. Fortunately @maerwald added missing alpine ghc bindists against integer-gmp (see Make work stack-9.2.1.yaml and enable pedantic (-WError) for cabal  #2606 (comment))
  • And then we have hit a weird bug only present in alpine + ghc-9.2.1 (and no in ubuntu + ghc-9.2.1) (see Use ghc+integer-gmp for alpine linux build release #2615 (comment))
• So it has become clear that we need restore the consistency between the workflows (including tests and benchmarks) and run all of them on alpine for the linux variant

[michaelpj]

I'm more worried about the first one. If we're going to force some build configuration (e.g. using integer-simple) in some workflow, we should do it in all of them, otherwise things will be inconsistent.

I'm less worried about GHC bugs. They happen from time to time, but it's less likely than solver issues IMO.

[jneira]

Well the first one is resolved, as .ghcup downloads ghc versions linked against integer-gmp for all our supported ghc versions. So i removed the particular build configuration for integer-simple and afaics the build configuration is the same now between workflows (#2615)

[jneira]

I'm less worried about GHC bugs. They happen from time to time, but it's less likely than solver issues IMO.

More frequent than desirable i am afraid. And more frequent in not so widely used systems like alpine i guess

[jneira]

From #2615 (comment)

It worths to note that ghc-9.2.1 in alpine seems to be fragile:

• "Alpine segfaults many tests in 9.2.1" https://gitlab.haskell.org/ghc/ghc/-/issues/20266
• "Alpine ci job is broken" https://gitlab.haskell.org/ghc/ghc/-/issues/20574

btw, someone has done some dogfooding with the alpine based hls executables? do we know they work for sure? They have not passed the test suite

[jneira]

btw, someone has done some dogfooding with the alpine based hls executables? do we know they work for sure? They have not passed the test suite

you can dowload the executables from the build artifacts: https://github.com/jneira/haskell-language-server/suites/5014931778/artifacts/147473084
i've triggered a build in this repo to make available them here too: https://github.com/haskell/haskell-language-server/actions/runs/1728847536#artifacts (the build still have not finished)

[jneira]

Hi,i've tried the linux executable in wsl and when opening a module with template haskell, i get an error in the top of the file:

Unexpected usage error
Dynamic loading not supported

This is with ghc-8.10.7
And no ide feature is working in the module.
Is this the expected behaviour? hls will directly not work in modules with th?

[jneira]

Is this the expected behaviour? hls will directly not work in modules with th?

cc @wz1000 @pepeiborra

I am not sure if start the new release as this behaviour would break all Linux uses where th is working now

[kokobd]

i've triggered a build in this repo to make available them here too: https://github.com/haskell/haskell-language-server/actions/runs/1728847536#artifacts (the build still have not finished)

@jneira I tried an executable from here and encountered the exact same error as yours.

My environment:

• ubuntu 20.04
• ghc 8.10.7 (installed by ghcup)

[jneira]

@pepeiborra @wz1000
sorry, but i will open a pr disabling the fully statically build for linux using alpine to unblock the release if i dont have any confirmation that is the expected behaviour (and we decide to keep it) or if it could work with some change here or in the user side

[Anton-Latukha]

1. Looked into Use alpine in all sensible workflows #2640.

2. Good idea to test on Alpine.
   Indeed, if it works in a minimal environment - it should work on the majority of other Linux'es.

3. Would note that Alpine has a caveat, it is not POSIX compliant by default, it relies on BusyBox & I encountered problems with that enough times in my former work to be quite aware of it. It seems to work perfectly, until suddenly something changed & it can not find something from most frequently POSIX support, or GNU Coreutils.

Changing from BusyBox to GNU Coreutils in Alpine - is simple as apk --no-cache add coreutils.

[Anton-Latukha]

If you want, I can tomorrow switch my scope. Would love to look more into how containers work in GitHub CI. & I used to do a lot of containerization & loved to optimize the use of containers to cache the setup, COW deduplication, etc.

I used to have a free autoupdate on container images. Leveraged DockerHub API, simply added webhook into IFFT to rebuild the image on schedule & was leveraging free rebuilds through DockerHub & so always had prebuilt images for main things.