test on Tier 2 platforms and make a prerelease for them

[geekosaur]

This runs overnight, so it doesn't bog down PRs.

I'm not sure the prerelease part will work; we'll just have to see.

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). scheduled workflows only run on master

Depends-on: #10363

[geekosaur]

About the only way this can be tested is to commit it, since it has to be on master and has to be scheduled by GHA.

[ulysses4ever]

What about the main validate workflow: should it avoid testing these now?

[geekosaur]

The whole point of this PR is that when #10363 (which is marked above as a Depends-on:) lands, Intel Macs won't be tested or prereleased at all.

[ulysses4ever]

Good!

[geekosaur]

There's a significant question here: how much of the validate workflow do we want to run? It could be argued that full validation on AArch64 is good enough, but it could also be argued that that's inviting bitrot. (If we want to run most or all of the validate workflow, I'll want to split that into reusable components that can be shared between this job and the main workflow.)

[ulysses4ever]

For posterity, it'd be good to comment why this wasn't merged

[geekosaur]

No, actually, I don't think so.

[geekosaur]

Reflavoring in terms of tier 2 platforms, several of which are built as part of a release but never validated. The hard part here will be fitting FreeBSD into it, since the release build is done on CircleCI instead of GitLab. I will probably take that from #9437, along with the target platform list (I expect, for example, at least one i386 build).

[geekosaur]

Some additional notes:

• I want to split validate.yml up into multiple local actions, so they can be shared between that and this. That will be a separate PR and will not change behavior.
• As above, we need to decide which checks will be done here.
• We may want to also think about splitting the validate.yml checks into PR and merge checks, the latter being more complete. That would also be a separate PR, and would depend on the first one.