docs: mention GitHub CI build artifacts in README

[ulysses4ever]

We often have to reference them, so maybe adding a reference to the README could save us some effort...

[Mikolaj]

Also, gitlab artifacts, citing @jneira:

https://discourse.haskell.org/t/request-for-testing-of-the-xdg-enabled-cabal-install/5200/3?u=jneira

and below in the same post is how to install from gitlab via ghcup (I wonder if one can install from github in this way and if there's any advantage).

[athas]

One way of doing this, which seems fairly common for other projects, is to have a GitHub "release" that is automatically updated on every commit. GitHub releases are mutable, so you only need a single one that you keep changing. This is pretty visible to users.

[Mikolaj]

Yes, such a release would be much more convenient that artifacts hidden in some of the CI jobs. PR welcome (this requires tweaks to GHA scripts and some Settings changes presumably).

[athas]

Not sure about Settings, but it does require GHA additions. As inspiration for someone who wants to embark on this, here are the salient parts from another Haskell project.

I don't remember any downsides or problems, although you'll have a GitHub-side tag nightly that keeps changing. As long as the release is marked as a "prerelease", no automated tooling that checks for new Cabal versions should be confused by the constantly changing release.

[ulysses4ever]

I also think no need in settings is required. @athas could you submit a PR with that snippet you referenced? A point of bike shedding: I don't like the title/tag "nightly" because it feels like it updates once a day. I'd call it "latest".

[ulysses4ever]

We'll also need a sizeable update to the Readme. A new item under "Ways to get the cabal-install binary", perhaps: "Continuous Integration products", with three subitems: GitHub prerelease, GitHub binaries in every PR, and GitLab.

[athas]

A point of bike shedding: I don't like the title/tag "nightly" because it feels like it updates once a day. I'd call it "latest".

This colour is perhaps problematic because some tools use the string "latest" to refer to "the latest proper release". Maybe "snapshot" or "prerelease"?

[ulysses4ever]

Indeed. How about head? Currently, our upload-artifact action uses cabal-head as the name of the file. Otherwise, pick what you prefer from those two.

I looked a bit more in the config you referenced: you may need to copy more than what you highlighted in your link.

[Mikolaj]

As a stop-gap before we have nightly pre-releases, would it make sense to extend building (no-assert) binaries on gitlab from all tags to all PR merges (if that's possible; alternatively, all pushes, that's almost the same)?

@bgamari: would that burden gitlab too much? We don't have a high traffic compared to GHC, I think.