attempt to use local actions

[geekosaur]

Extremely experimental, and with all the limitations and restrictions I keep finding in GitHub Actions it'll probably fail in the messiest way it can.

At present this is incomplete but sufficient to see if this has any chance of working to begin with. If it somehow does, I'll look into abstracting out the other sub-jobs, then making an overnight validate for Tier 2 platforms and probably a prerelease job (which would fix the recently revealed problem where if there is no need to rebase on merge, no prerelease is made).

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). (No point in backporting, as even the LTS prerelease part has to live on master.)

[geekosaur]

First cut at overnight prerelease jobs now done. They also bring back Intel Macs, still without validate though (that awaits the tier-2 job). I also dropped bootstrap as it looks like there's nothing to be gained there. (None of this has been pushed yet.)

[geekosaur]

  # We never validate this. We would probably have caught https://gitlab.haskell.org/ghc/ghc/-/issues/25087
  # if we had. (I'll do this in Tier 2 unless someone thinks there's a good reason to do it here; the need
  # for a container means it can't be shared reasonably unless everything is changed to use one like
  # https://github.com/haskell/cabal/pull/9437 does in its release workflow.)
  build-alpine:

Interestingly, it looks like i386 jobs are runnable in a container, although I'm not sure what limitations exist. Which means I can at least attempt to do them in Tier 2 as well.

[geekosaur]

First cut at overnight Tier 2 validation added: Intel Macs, the validation we haven't been doing on Alpine, and i386 (Debian 11, the oldest version I could find on Docker Hub). No FreeBSD as yet, I still haven't dug into what it will take to get all this stuff into a Cirrus CI job (probably writing a script to do it all).

I also need to wedge the i386 job into the prerelease jobs, I think. Probably the same way Tier 2 works: generalize the Alpine job into a containers job.

[geekosaur]

I'm pushing forward on this first cut because of the prerelease workflows. Refinement, including likely debugging of scheduled workflows, can come later.

I'm also trying to figure out if there's some hacky way around GitHub only sending notifications about scheduled workflows to the last user who edited the schedule.

[ulysses4ever]

Amazing, thanks!

[ulysses4ever]

But in a follow-up, we really need to sweep the less-relevant comments (like # look familiar?): They make the reader not want to read the comments at all because of the low signal/noise.

[geekosaur]

They're not entirely pointless: they mark the (IMO unnecessary except that GHA is stupid) duplications.

[ulysses4ever]

well, it's too subtle. I'd appreciate something less playful and more direct. E.g. for the matrix, duplicate matrix yet again see [Note: matrix duplication].

[geekosaur]

At this point I do not recommend merging this unless you have someone, preferably several someones, who understand it; otherwise your bus factor situation is looking pretty dire. If necessary I can expand the prerelease jobs out to full form and submit those separately, as they're the most urgent part of this and I don't want to leave you in a bad situation.

[Kleidukos]

Let's put this PR away for the moment

[9999years]

At this point I do not recommend merging this unless you have someone, preferably several someones, who understand it; otherwise your bus factor situation is looking pretty dire.

Ehhh, GitHub Actions stuff is kinda always like that. It's usually not too miserable to make small tweaks to, but changes in design goals require rearchitecting, as I think you're running into with this!

I haven't read over this with eagle eyes but it looks largely fine to me. A couple notes:

• Try running over this with actionlint and see if it catches anything.
• It might be worth porting some of the logic to Haskell, like cabal-validate; then, it's easier to test more of the logic locally, and you can cut down on the scary GitHub Actions shell-scripts-templated-YAML stuff. (In this design, the actions ideally become fairly thin wrappers that set up some inputs and then call the relevant script with the relevant arguments.)