Distribute Alpine binaries

[pepeiborra]

As agreed in #2431 we want to be distributing Alpine binaries. Unfortunately Github doesn't offer any Alpine workers, so we cannot reuse the existing build Github action to generate them.

However, the Gitlab CI contributed by @hasufell is already generating these binaries, e.g.:

https://gitlab.haskell.org/maerwald/haskell-language-server/-/pipelines/44731

Things to be done:

1. Record releases in the Gitlab project in order to generate release metadata
2. Modify the downloader to fetch the Alpine Linux binaries from Gitlab: https://gitlab.haskell.org/maerwald/haskell-language-server/-/pipelines/44731

I don't know if we want to grab only the Linux binaries from Gitlab, or also the Windows and Mac OS binaries.
This would also be a good opportunity to distribute Apple M1 binaries for the supported GHC versions (#1896)

[hasufell]

Unfortunately Github doesn't offer any Alpine workers, so we cannot reuse the existing build Github action to generate them.

You can use Github actions for that too: https://github.com/hasufell/stack2cabal/blob/master/.github/workflows/release.yaml

But IMO, it would make more sense to focus all release CI on GitLab.

[jneira]

I am not against the use of gitlab releases but we have to consider some points:

• To have only the release build and no the test or bench ones could make the release build less reliable. We are exercising the gh setup for every pr (and recently also in master), executing the test suite and bench for the workflow artifact. So if we want to keep the gitlab release up to date and reliable we should move or copy the bench and test workflows to gitlab and sync automatically both repos.
  • If we move the test and bench workflows we should find a way to keep the branch protection rules in githubagainst the gitlab workflows. Ultimately it would ask to make gitlab the main repo.
• We should complete the gitlab scripts to make it generate artifacts matching the gh scheme: one tar per suppported ghc and os+arch and one tar per os+arch with all ghc versions for ghcup. It lacks a supported minor ghc versions (8.10.6) and other minor things like generating the sha256sums. Not a big deal but has to be done.
• hls workflows will have to compete for ci resources with other gitlab projects, specially with ghc itself, which consumes lot of ci resources. We will lose the resources boost github gives us recently.
• As noted we should have to change the vscode extension to fetch releases from gitlab. We should keep compatibility with github now we are downloading old reelases, or copy all the missed releases to gitlab.

[hasufell]

To have only the release build and no the test or bench ones could make the release build less reliable

Why?

[jneira]

Well if we only trigger the build once in a month they will get out of date with more probabilities
And we will not check the executables against the test suite or the bench. They will use the same sources but tests could fail and perf be different due to the build itself. Less probable but still possible.

[wz1000]

As noted we should have to change the vscode extension to fetch releases from gitlab. We should keep compatibility with github now we are downloading old reelases, or copy all the missed releases to gitlab.

We could host all the binaries on downloads.haskell.org and change the extension to use that.

[hasufell]

Well if we only trigger the build once in a month they will get out of date with more probabilities

Then we trigger it every day.

And we will not check the executables against the test suite or the bench. They will use the same sources but tests could fail and perf be different due to the build itself. Less probable but still possible.

That shouldn't be an issue when the dependencies are frozen and the same alpine container is used.

[jneira]

Then we trigger it every day.

We will take more resources but if that is not an issue for ghc, it will do the job

That shouldn't be an issue when the dependencies are frozen and the same alpine container is used.

so we have to change the GitHub workflow anyways

[hasufell]

Then we trigger it every day.

We will take more resources but if that is not an issue for ghc, it will do the job

I don't think that's an issue.

That shouldn't be an issue when the dependencies are frozen and the same alpine container is used.

so we have to change the GitHub workflow anyways

No, just add freeze files or use stack to build the releases.

[jneira]

No, just add freeze files or use stack to build the releases.

We have the hackage index pinned but i wanted to mean we will have to use the alpine docker image in gh workflows to test/bench the same executable which would be released.

[pepeiborra]

Can we build HLS in Alpine with GHC 8.*? integer-gmp is a transtitive dependency and I'm told it's not available in Alpine.

https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true

[hasufell]

Can we build HLS in Alpine with GHC 8.*? integer-gmp is a transtitive dependency and I'm told it's not available in Alpine.

https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true

It is available. It, unfortunately, depends on the bindist used. Some alpine bindists use integer-simple, others integer-gmp. I'm not 100% sure about 8.10.7, but in worst case we can build a bindist from scratch.

ghcup will always prefer integer-gmp ones.

I believe I raised this before with @bgamari

https://gitlab.haskell.org/haskell/haskell-language-server/-/jobs/869440

[pepeiborra]

Can we build HLS in Alpine with GHC 8.*? integer-gmp is a transtitive dependency and I'm told it's not available in Alpine.
https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true

It is available. It, unfortunately, depends on the bindist used. Some alpine bindists use integer-simple, others integer-gmp. I'm not 100% sure about 8.10.7, but in worst case we can build a bindist from scratch.

ghcup will always prefer integer-gmp ones.

I believe I raised this before with @bgamari

https://gitlab.haskell.org/haskell/haskell-language-server/-/jobs/869440

That job is using the integer-simple build, downloaded by ghcup in line 102: https://gitlab.haskell.org/haskell/haskell-language-server/-/jobs/869440#L102

It's the same bindist installed by haskell/actions/setup: https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true#step:5:22

Digging deeper, I found this workaround:

haskell-language-server/.gitlab/ci.sh

Line 50 in e74cf55

echo -e 'package blaze-textual\n flags: +integer-simple' >> cabal.project.local

[hasufell]

Can we build HLS in Alpine with GHC 8.*? integer-gmp is a transtitive dependency and I'm told it's not available in Alpine.
https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true

It is available. It, unfortunately, depends on the bindist used. Some alpine bindists use integer-simple, others integer-gmp. I'm not 100% sure about 8.10.7, but in worst case we can build a bindist from scratch.

ghcup will always prefer integer-gmp ones.

I believe I raised this before with @bgamari

https://gitlab.haskell.org/haskell/haskell-language-server/-/jobs/869440

That job is using the integer-simple build, downloaded by ghcup in line 102: https://gitlab.haskell.org/haskell/haskell-language-server/-/jobs/869440#L102

It's the same bindist installed by haskell/actions/setup: https://github.com/haskell/haskell-language-server/runs/4487926042?check_suite_focus=true#step:5:22

Digging deeper, I found this workaround:

haskell-language-server/.gitlab/ci.sh

Line 50 in e74cf55

echo -e 'package blaze-textual\n flags: +integer-simple' >> cabal.project.local

Wish I would always remember what I did 2 weeks ago. Not sure we'll get performance penalty for that?

[jneira]

maybe we should test and bench the same executable using alpine to check the possible perf regression

[pepeiborra]

Go ahead if you want to, but I don't think there's anything to worry about