make sure cabal-install is compatible with Cabal

[geekosaur]

See #9833

If a ghc ships with a compatible Cabal, it will be preferred by the solver on cabal install cabal-install; the new cabal-install should in fact be compatible. So we test this on release branches that have been included in at least one GHC release.

Fixes: #9833
Fixes: #9835
Fixes: #9838
Fixes: #9863

CI note: there's really no way to test this, aside from reproducing #9833 for which it's a bit too late. Testing will only be possible with the 9.12 branch and future release branches. As such, manual CI would mean making an sdist of the HEAD of 9.12 branch, then trying to build that sdist against 9.10.1 (which is essentially what this does, except that it won't actually do that test until it's backported). Note that that build may well succeed, because I've been trying to be careful with backports specifically to avoid repeating the mistakes we made with 3.10.3; the point of this PR is to try to catch that kind of failure in CI before we make a release with a breaking change.

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).

[ulysses4ever]

validate.yml is already close to incomprehensible. Any chance we can do it as a separate workflow? As a bonus, you won't need the if's.

[geekosaur]

Problem is, I need the sdists from an earlier step, or else generate them myself and then make sure the tree doesn't interfere with my install from the sdist somehow.

[geekosaur]

Also, it's bad enough that matrix.ghc has to be updated in two places because it can't be shared; it'd be worse across multiple files. (Well, it can be shared, but it'd need to be stored as JSON in a separate file. I'm not sure if that's better or worse.)

[ulysses4ever]

Repeating some steps in a separate workflow may be a lesser evil, I think.

Storing the matrix in a json file sounds like a reasonable idea too.

[geekosaur]

Can't test this further without backporting it to a release branch. Although it'd be nice if I could identify a PR targeting master; I don't think that information is available in GHA. (ETA: it is, so the sdist jobs shouldn't run except on release branches now.)

[geekosaur]

As a bonus, you won't need the if's.

Actually, I would; they just become conditions for the workflow to run instead of conditions for various steps to run.

[ulysses4ever]

Which conditions would you check on a standalone workflow? You can select the platform, the GHC version, and the target branch declaratively. Not that this was super important. Most of all, I'm concerned and wary about adding anything to validate.yml at this point.

[Mikolaj]

That's amazing!

[geekosaur]

Most recent change corrected it to actually test the problematic case: it now succeeds trivially if Cabal and friends come from Hackage, and only runs the actual test if they are bootlibs. This also means --prefer-oldest is irrelevant as the bootlib will always be preferred.

This also means it shouldn't test the latest release of GHC branches, it should test the first release. (Which in turn means that there wouldn't be any duplication with matrix.ghc in validate.yml.)

[ulysses4ever]

Cool!

[geekosaur]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10373 make sure cabal-install is compatible with Cabal (backport #10264) has been created for branch 3.12

[geekosaur]

@mergify backport 3.14

[mergify]

backport 3.14

✅ Backports have been created

• Backport to branch 3.14 not needed, change already in branch 3.14

[geekosaur]

Note: it's fine to do this post-release, since it will only do anything once a ghc is shipped with Cabal 3.14.