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.