Add CI runners on emulated hardware

[mmuetzel]

Pull request purpose

Use a GitHub action to install Alpine Linux for different, less common architectures that are emulated with qemu (apart from x86).
Additionally, Alpine Linux is one of those distributions that are based on musl (instead of glibc).

This increases coverage for different configurations in CI.

Detailed changes proposed in this pull request

This PR adds GitHub action runners that build on Alpine Linux. It uses an action from the GitHub marketplace to install the required packages and set up qemu for subsequent steps (if necessary to emulate the respective architecture).

The emulated hardware can be slow. Especially compiling C++ objects seems to take quite some time. In preliminary tests, building ARPACK in the given configuration on emulated hardware took about 30 minutes.
This PR uses ccache to try to mitigate that. In preliminary tests, building with a hot cache reduced the build time to about 10 minutes on emulated hardware.
Unfortunately, current versions of ccache aren't able to cache Fortran objects. So, it is only used for the C and C++ objects.

To reduce the minutes that are used by this action, a concurrency rule is used to skip running the action if changes are pushed in quick succession.

[fghoussen]

Thanks! Still need to have a closer look. @sylvestre: what do you say?

[sylvestre]

why not ?
But i don't see the execution of the tests. Which is what really matters IMHO

[mmuetzel]

why not ?
But i don't see the execution of the tests. Which is what really matters IMHO

Thank you for checking this PR.

Which tests should be executed? Are you referring to these: https://github.com/opencollab/arpack-ng/pull/458/checks?notification_referrer_id=NT_kwDOA-DQjrQxMTA3MDUyOTc5OTo2NTA2NTEwMg#step:11:6
Are there more tests that could be executed?

[mmuetzel]

I triggered the CI again by a minor change to one comment to check if the ccache is working as expected.

The following tables show the duration of the CI runs. Because the build and the test steps have the largest contribution, I also listed them separately.
(Overall duration might also depend on the current load of the GitHub-hosted runners.)

With cold cache:

architecture	total	build	test
x86	4:42	3:31	0:47
aarch64	45:12	32:10	12:20
armv7	41:28	28:55	11:59
ppc64le	47:52	34:16	12:56
riscv64	38:18	26:58	10:38
s390x	46:00	33:47	11:19

With hot cache (2nd run):

architecture	total	build	test
x86	1:42	0:43	0:46
aarch64	23:43	10:52	12:15
armv7	22:23	10:01	11:48
ppc64le	25:33	11:42	12:50
riscv64	20:45	9:24	10:40
s390x	22:59	10:57	11:16

As you can see, using a hot ccache has hardly any influence on the runtime for the tests (as expected).
But the build time decreases significantly if the cache is hot.

[fghoussen]

Can we afford such build/run times on the CI: @sylvestre what do you think?

[mmuetzel]

Can we afford such build/run times on the CI: @sylvestre what do you think?

Minutes for GitHub-hosted runners should be free (as in no costs) for open source projects.
Is there a non-open source mirror of this repository where these minutes would be billed? It that is a concern, we could probably limit this action to run only on opencollab/arpack-ng (but not for mirrors).

Please, let me know how to proceed.

[sylvestre]

Lgtm

I am curious how the testing works? Emulation?

[mmuetzel]

I am curious how the testing works? Emulation?

IIUC, the action from the GitHub marketplace that sets up the Alpine build environment uses qemu to emulate non-x86 (32-bit or 64-bit) architectures:
https://github.com/jirutka/setup-alpine?tab=readme-ov-file#highlights

In the meantime, GitHub seems to aim at deploying (native) ARM-based Windows and Linux runners for open source projects by the end of this year:
https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/

These runners are available to our customers on our GitHub Team and Enterprise Cloud plans. We expect to begin offering Arm runners for open source projects by the end of the year.

When that happens, the CI rules could probably be adapted to no longer emulate aarch64 (and armv7?).