Set up arm64 graviton CI using cirun

[steppi]

This PR adds CI jobs for the arm64 graviton architecture. It uses cirun to run github actions jobs on AWS. I have this set up and working on my personal fork of OpenBLAS: /~https://github.com/steppi/OpenBLAS/actions. The cirun app should be installed for this repository using the steps described here. @xianyi, @martin-frbg, could you please create a cirun account and connect it to this repository? In case you're wondering about AWS costs/admin: Quansight has an AWS account which can be used for the necessary compute to run these jobs, and we will take care of paying the bills and resolving potential issues with it going forward. Note that we set this up with support from the Sovereign Tech Fund, and that stretches to the end of 2024 - and we are committed to taking care of it beyond that end date as well."

Note: I have attempted to skip CI for this initial PR because the cirun jobs will fail without a connected cirun account and other jobs are not relevant. It looks like I only managed to skip github actions jobs.

cc @martin-frbg, @rgommers, @mattip, @honno

[Mousius]

Hi @steppi, thanks so much for this. Glad to see SVE testing enabled in OpenBLAS! Let me know if I can assist in running and maintenance here.

Just curious why you've chosen to go with cirun over integrating directly with something like Cirrus (https://cirrus-ci.org/guide/supported-computing-services/#aws). What's the added value with cirun?

[steppi]

Hi @steppi, thanks so much for this. Glad to see SVE testing enabled in OpenBLAS! Let me know if I can assist in running and maintenance here.

Thanks @Mousius, will do.

Just curious why you've chosen to go with cirun over integrating directly with something like Cirrus (https://cirrus-ci.org/guide/supported-computing-services/#aws). What's the added value with cirun?

That's a good question. Primarily, the team I work on has more experience working with cirun, we know and work with the lead developer, and we're confident in its ability to limit our exposure to unexpected cost spikes from AWS. Running jobs on EC2 through Cirrus is less well known to us, but we have been considering it and I'm currently working on setting it up on my fork with the intent to submit another PR for the Cirrus option today.

[steppi]

@Mousius I took an initial stab at getting these jobs set up with Cirrus on my personal fork here and they are passing successfully. I'm going to hold off on making a PR until I learn more about the plan for letting the OpenBLAS Cirrus account have access to Quansight's AWS credentials in a trusted way. We have a plan in place already for cirun.

At the moment the only difference between the Cirrus jobs and the Cirun jobs is the complexity of key logic for the build cache. The following behavior is not available out of the box on Cirrus, and would need to be re-implemented. I don't think this is a blocker though for using Cirrus.

 # We include the commit sha in the cache key, as new cache entries are
          # only created if there is no existing entry for the key yet.
          # GNU make and cmake call the compilers differently. It looks like
          # that causes the cache to mismatch. Keep the ccache for both build
          # tools separate to avoid polluting each other.
          key: ccache-${{ runner.os }}-${{ matrix.build }}-${{ matrix.fortran }}-${{ github.ref }}-${{ github.sha }}
          # Restore a matching ccache cache entry. Prefer same branch and same Fortran compiler.
          restore-keys: |
            ccache-${{ runner.os }}-${{ matrix.build }}-${{ matrix.fortran }}-${{ github.ref }}
            ccache-${{ runner.os }}-${{ matrix.build }}-${{ matrix.fortran }}
            ccache-${{ runner.os }}-${{ matrix.build }}