check compatibility with GHC prereleases

[geekosaur]

This unnecessarily runs even when a prerelease isn't active, but if it fails then then we have bigger problems (like we do right now with a buggy 3.14.1.0 released).

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[geekosaur]

I filed haskell-actions/setup#104 over the complete inability to get a path or actual version specific to the latest-prerelease install. (I suspect they'll reject it, since it's ghcup-specific but they also use Chocolatey and (for some reason) hvr's ancient unmaintained PPA.)

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[ulysses4ever]

There are special arrangements for testing latest GHCs, including prereleases, which might need to be updated or could be re-used in this work. Note: In the cabal meeting, I said it's only prerelease-related, but in fact they are handy when a fresh GHC release drops, so they shouldn't be scrapped altogether, perhaps.

In particular,

• a config file with head.hackage and allow-newer's:

  • https://github.com/haskell/cabal/blob/master/project-cabal/ghc-latest.config
    It's used in CI these days:

  • cabal/cabal.validate.project

    Line 2 in c2d8353

    import: project-cabal/ghc-latest.config

• ghcup prerelease channel, which can be killed:

  cabal/.github/workflows/validate.yml

  Line 133 in c2d8353

  ghcup-release-channel: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.8.yaml

[ulysses4ever]

In general, the PR description doesn't say why this can't be done as a part of the main validate workflow or why it's preferable to do it separately. Such explanation would be important for me.

[geekosaur]

So, there are three reasons we don't want to do this in validate.yml:

1. we don't do a validate, and it's hard to avoid doing that in a validate run
2. this specifically looks for the warnings that cabal doesn't support the prerelease ghc version
3. we may not want this to block merging, which validate necessarily does

[geekosaur]

(And yes, I had forgotten about this PR; it's one I fired off and promptly forgot about, expecting it to come back on my radar if/when reviewed.)

[ulysses4ever]

we don't do a validate, and it's hard to avoid doing that in a validate run
this specifically looks for the warnings that cabal doesn't support the prerelease ghc version

So, just the warning about unsupported GHC... This PR should be renamed accordingly, e.g. check "Unsupported GHC" message in CI because the current title seems like it claims much more. Frankly, it feels like adding a whole new CI workflow to catch this single issue is a bit much. OTOH, we were bitten by it in the past and not once, so I guess I'm in support. The title of PR just derailed me.

we may not want this to block merging, which validate necessarily does

This is fair. I thought in the call you were talking about running it on corn. This would make more sense to me than having it run on PRs and getting people confused about what this is. Can you change the on: field to only use cron?

---

I think we do want a full validate on prereleases, and past work showed that this is simple to set up (#8754). In general, if you don't run tests, you can't make sure to catch real issues. Also, #8754 had a fair amount of copy-paste because back then the haskell/setup action didn't support the prerelease channel (I think). These days, adding a prerelease is as easy as extending the validate matrix and adjusting the conditional project-cabal/ghc-latest.config about the version of GHC we want to special-case with the allow-newers and head.hackage.

Running the full validate will also solve the problem that you're trying to solve here: it will fail when an unsupported GHC is detected. The only remaining issue that I don't know how to solve is how to run it only on cron so that we don't blow up the contributors. If we don't want to create a whole copy of validate that runs on cron for just prereleases, it may require some clunky YAML conditionals, which I generally detest. But maybe in this case they wouldn't be too bad.