Add CI on Github Actions for macOS

[blapie]

Do we understand what is going on with the cancelled actions? I don't remember cancelling anything, so I retriggerred a run but the re-run got cancelled again. https://github.com/shibatch/sleef/actions/runs/9217334465

[blapie]

Regarding your message about the cost of macos runners. If I understand the pricing policy correctly, since SLEEF is a public repository we have access to most runners for free, including the macos ones.

In this case I'm happy to go an merge this PR, provided all checks pass.

[Andarwinux]

Do we understand what is going on with the cancelled actions? I don't remember cancelling anything, so I retriggerred a run but the re-run got cancelled again. https://github.com/shibatch/sleef/actions/runs/9217334465

I also encountered this in my repo, I found that ubuntu-24.04 runner may be faulty, github seems to be AB testing for ubuntu-latest, my workaround is to hardcode it to 22.04 for now.

Regarding your message about the cost of macos runners. If I understand the pricing policy correctly, since SLEEF is a public repository we have access to most runners for free, including the macos ones.

In this case I'm happy to go an merge this PR, provided all checks pass.

In fact GHA has a subtle hidden “quota” for public repositories, which can lead to repos being banned if you go too far. In addition, I'm concerned that this may cause some private forks to accidentally use up their limited quota.

[blapie]

In fact GHA has a subtle hidden “quota” for public repositories, which can lead to repos being banned if you go too far. In addition, I'm concerned that this may cause some private forks to accidentally use up their limited quota.

I wonder if we are ever gonna be close to these quota in practice, but I understand the issue with forks. Can the workflow be triggered at a given frequency instead of at pre/post-commit, say weekly? Is it safe to let the jobs be triggered manually?

[Andarwinux]

Can the workflow be triggered at a given frequency instead of at pre/post-commit, say weekly? Is it safe to let the jobs be triggered manually?

Sure, just use schedule. Manual trigger would require repo members to keep an eye on GHA, which I think could be a significant burden.

I think the main bottleneck in CI at the moment is QEMU-based testing, so maybe consider split it into separate workflows, run build CI for each commit, and run testing CI periodically.

[blapie]

Thank you for your insight.

Sure, just use schedule. Manual trigger would require repo members to keep an eye on GHA, which I think could be a significant burden.

Agreed, that is quite a fair price to pay. That is also probably an easier way to monitor resource usage in general, since we know almost exactly what is ran and how often.

I think the main bottleneck in CI at the moment is QEMU-based testing, so maybe consider split it into separate workflows, run build CI for each commit, and run testing CI periodically.

Absolutely, we might simply split native and cross jobs into different workflows. Then, use conditionals to run native build+test and cross build on each commit and run cross tests only periodically.

Please leave the on section of your worflows as is for now we will adjust all workflows once your new ones are merged.

[blapie]

Just re-ran the failing workflows as the issue with ubuntu runners seem to have been resolved. Otherwise ready to merge the new workflow files.

[blapie]

Are you happy for me to merge?

[Andarwinux]

Yes, LGTM.

[blapie]

Thanks again for an outstanding contribution, this is very much appreciated! I'll make sure we have more control over CPU runners usage by re-organising workflows in the upcoming days.