CI: stop validating GHC 7 (backport #9886)

[mergify]

Changes:

• bump GHC_FOR_RELEASE to 9.4.8
• bump action versions
• uniform quoting style
• satisfy actionlint
• fix order: setup Haskell before cache restore (uses setup.haskell-outputs)
• use --ignore-project in cabal install hackage-repo-tool
• closes cabal-testsuite fails early on with linker error on Windows since GHC 9.6 #8858: deleted comment
• closes CI validate-old-ghcs broken after haskell-actions/setup upgraded to node20 #9858 by dropping container and use ghcup to setup ghcs

---

This is an automatic backport of pull request #9886 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 29dc53c has failed:

On branch mergify/bp/3.12/pr-9886
Your branch is ahead of 'origin/3.12' by 1 commit.
  (use "git push" to publish your local commits)

You are currently cherry-picking commit 29dc53c33.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   .github/workflows/validate.yml

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[geekosaur]

This is bizarre. It looks for all the world like one hunk is being applied in reverse.

[geekosaur]

Starting to think GitHub has a poltergeist. Updated and rebased locally, pushed it up, GH insisted there was a new conflict afterward and wanted to revert the OS X CI fix. Oy.

[Mikolaj]

Thank you for working on that. Note that it's not terribly urgent (it prevents a CI breakage once github stops providing old node versions, which can happen any time now). I brought it up, because I thought it's responsible for the conflicts with the main CI fix PR backport.

[Mikolaj]

So, is this ready for merge?

[Mikolaj]

@mergify rebase

[mergify]

rebase

❌ Base branch update has failed

Git reported the following error:

Rebasing (1/12)
Auto-merging release-notes/Cabal-3.12.0.0.md
Auto-merging release-notes/WIP-cabal-install-3.12.x.0.md
CONFLICT (content): Merge conflict in release-notes/WIP-cabal-install-3.12.x.0.md
error: could not apply 271ae8fe5... 3.12 changelog fixup (#9922)
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 271ae8fe5... 3.12 changelog fixup (#9922)

[Mikolaj]

I haven't looked closely, but if it's just the backport with the conflicts fixed, then yes, I'd recommend merging it in.

[Mikolaj]

Let me squash so that rebase doesn't fail.

[Mikolaj]

@mergify squash

[mergify]

squash

✅ Pull request squashed successfully

[Mikolaj]

@mergify rebase

[mergify]

rebase

☑️ Nothing to do

• any of:
  • #commits-behind>0 [📌 rebase requirement]
  • #commits>1 [📌 rebase requirement]
  • -linear-history [📌 rebase requirement]
• -closed [📌 rebase requirement]
• -conflict [📌 rebase requirement]
• queue-position=-1 [📌 rebase requirement]

[Mikolaj]

Please kindly set the merge label once you are satisfied this is not borked.

[Mikolaj]

I addressed this to @geekosaur or @ffaf1, since you take care of the 3.12 backports and we need another pair of eyes, given the convoluted history of some of these backports.