Closed mmuetzel closed 5 months ago
Thanks! Still need to have a closer look. @sylvestre: what do you say?
why not ? But i don't see the execution of the tests. Which is what really matters IMHO
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?
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.
Can we afford such build/run times on the CI: @sylvestre what do you think?
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.
Lgtm
I am curious how the testing works? Emulation?
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
?).
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 ofccache
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.