CI: add GHC 9.6.1

[ulysses4ever]

Time to rock 🤘

Usual Blockers

• Update our own bounds on things like base, unix, etc.
• haskell/actions needs to support the new GHC.
• Dependencies require allow-newer:
  • rere Allow base-4.18 ulysses4ever/rere#20 Allow transformers-0.6 ulysses4ever/rere#19
  • cabal-plan Support base 4.18 (ships with GHC 9.6) haskell-hvr/cabal-plan#91
  • windns
  • Aeson and some of its deps. GHC 9.6 compatibility: bump ghc-prim and template-haskell upper bounds one notch aeson#1012
  • tree-diff Support GHC-9.6.1 (including on Hackage) haskellari/tree-diff#71
• As long as cabal versions are bumped (see Bump versions and deps on master branch to 3.11 and regenerate bootstrap files #8844 for this release), cabal-testsuite needs the latest release of cabal-install (more discussion: Default cabal.project in cabal repo fails with cabal-install older than latest release; hard to diagnose #8133).

Unusual Blockers

• All install methods for cabal 3.8.1.0 failed actions#188 (fixed upstream)
• cabal update is not run? actions#203 (fixed upstream)
• Windows fails since 9.6 prerelease. Tracking: cabal-testsuite fails early on with linker error on Windows since GHC 9.6 #8858 and disable that combination (9.6.1@Win) for now.
• *-suite validation fails on 9.6 altogether due to the mysterious "double directory" problem described in Hack around CI problems by sudo chown and disabling cache for Windows validate #8739. Disabling it for now.

TODO

• create an issue for the "double directory" issue and make sure *-suite validation is reenabled after it's solved.

• Bump minor versions of the previous computer series. Don't forget about GHC_FOR_RELEASE and the friends.

[Mikolaj]

@ulysses4ever: would perhaps bumping cabal on master to 3.11 help with this? If so, I can prioritize.

[ulysses4ever]

@Mikolaj oh it hasn't been? I think that's the reason of one of the failures, yes (number three in the "Usual blockers" list in OP). There's no rush though: do it when you feel it's the time. This PR can wait.

It seems that putting cache-restore in front did help with haskell/actions#203

[Mikolaj]

Version bumps on master: #8844

[ulysses4ever]

I rolled back cabal install in CI to 3.8 because on this branch the versions have not been updated and therefore cabal-testsuite requires 3.8. But I get a failure "All install methods for cabal 3.8.1.0 failed" foir some reason...:

• https://github.com/haskell/cabal/actions/runs/4409245230/jobs/7725298762

It didn't happen with 3.10...

[Mikolaj]

This seems broken upstream. Let's see if it works fine (again with 3.10) once the version bump PR lands.

[andreasabel]

Great work, rock and roll!!

It seems like you accidentially but effectively turned of caching of ~/.cabal/store.

[andreasabel]

@ulysses4ever wrote:

But I get a failure "All install methods for cabal 3.8.1.0 failed" foir some reason...:

Well this is exactly haskell/actions#202, as analysed by @Mistuke: The setup action installs cabal 3.10.1.0 already with ghc, and then the subsequent attempt to install 3.8.1.0 chokes when trying to handle the 3.10.1.0 generated config file.

[ulysses4ever]

@andreasabel well, I must say: you put it much more clear than I was able to distill from that thread. Thank you!

I thought some sort of workaround had been deployed though? Mistuke said that it should be 3.8 now? I can try to explicitly rm the config perhaps.

[ulysses4ever]

Otherwise, thanks for the review! I'll look into actionlint.

[Mikolaj]

The master version bump PR is merged.

[andreasabel]

@ulysses4ever : I fixed the haskell setup action v2 now, based on the advice by @Mistuke. Please try again!

[ulysses4ever]

Oh no, why is it trying to build Cabal-syntax-3.8.1.0... https://github.com/haskell/cabal/actions/runs/4409245230/jobs/7728945807#step:13:788

[Mikolaj]

Oh no, why is it trying to build Cabal-syntax-3.8.1.0... https://github.com/haskell/cabal/actions/runs/4409245230/jobs/7728945807#step:13:788

How about rebasing on master (with the version bumps)?

[ulysses4ever]

How about rebasing on master (with the version bumps)?

Well, this is a good point and a possibility I had in mind. But I thought that moving one thing at a time (in this case, the version of GHC) may be easier. I can try to rebase, yes. I may not have time to for a day or two though.

[Mikolaj]

No rush. BTW, yet another possibility for the CI cache problem resolution may be to reset the whole cache (first only in the PR, to verify) and so switch to XDG completely. Then the result of cabal update is properly found and used.

[ulysses4ever]

All right, useless GitHub wouldn't run CI because of conflicts with master (TIL...), so I had to rebase on master and, therefore, pull the versions bump from #8844. Now let's see...

[andreasabel]

Yes!!

[ulysses4ever]

@Mikolaj on the topic of bumping minor versions. Our GHC_FOR_RELEASE is currently at 9.2.3. Do you want me to bump it to 9.2.7 or leave the 9.2 series alone. We could also have two 9.2.x compilers, I presume.

[Mikolaj]

Yes, I think bumping it all makes sense and I'd keep only the newest version. I waited with touching the gitlab script until after the release, so this is a good moment now.

[ulysses4ever]

@mergify backport 3.10

[mergify]

backport 3.10

✅ Backports have been created

• #8899 CI: add GHC 9.6.1 (backport #8840) has been created for branch 3.10

[Mikolaj]

Hurray!

[ulysses4ever]

Yep, this was a long ride. Not sure when I have energy to attend to a backport...