try Apple AArch64 again

[geekosaur]

Let's see if the runner has stabilized yet. Also, fixed the arch issues (validate no longer assumes everything is x86_64).

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]

It'd be great to have this working and add it to the set of pre-release binaries. Many people are using ARM silicon from Apple these days.

Godspeed!

[geekosaur]

If you look at it, adding it to the prerelease (and adding support for archs other than x86_64 in the process) is part of what this PR does.

[geekosaur]

It's a good sign that it's now the Windows jobs that are slowest. (That one someone like jasagredo will have to figure out.)

[geekosaur]

Question: a large part of my objective here was to speed up the Mac builds, but in the process all the Intel builds were lost. Do we want to support those some other way (e.g. overnight builds), or re-add them for the ghcs that only work on Intel, or something else?

[ulysses4ever]

Nice!

[geekosaur]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10399 try Apple AArch64 again (backport #10363) has been created for branch 3.12 but encountered conflicts

[geekosaur]

@mergify backport 3.14

[mergify]

backport 3.14

✅ Backports have been created

• #10400 try Apple AArch64 again (backport #10363) has been created for branch 3.14

[Mikolaj]

Do we want to support those some other way (e.g. overnight builds), or re-add them for the ghcs that only work on Intel, or something else?

I think, given the complexity of our CI and how often it breaks (including due to external reasons), optimizing for CI maintenance should be the priority and compromises are fine (e.g., only running some tests on Intel Macs). It's better to have less exhaustive CI that works and doesn't consume all out maintenance budget than the other way around. So I support your approach.