Use Cirrus also for Aarch64 CI

[giordano]

Based on giordano/Cuba.jl#41. CC: @ararslan

[giordano]

Scheduling was delayed due to a concurrency limit on community tasks
Consider upgrading to a $10/month plan to get 2x the limits on any public and private repository

@ararslan not sure this is a good option 😬

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@cb51595). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #47   +/-   ##
=========================================
  Coverage          ?   55.04%           
=========================================
  Files             ?        7           
  Lines             ?      218           
  Branches          ?        0           
=========================================
  Hits              ?      120           
  Misses            ?       98           
  Partials          ?        0           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ararslan]

not sure this is a good option

What do you mean? GitHub Actions also has a limit on the number of concurrent jobs, it's just as bit higher than Cirrus' limit. Also "community tasks" here refers to jobs for open source repositories running on the free tier and AFAIK is per repo, not like all OSS repos share a single concurrency pool.

[giordano]

Well, none of the aarch64 jobs on Cirrus had started when I posted the message, and that was more than 12 hours after I opened the PR. When codecov posted the message some of them were running, but this was about 24 hours after opening the PR. And judging by https://cirrus-ci.com/github/JuliaPackaging there aren't many other repositories using Cirrus.

[ararslan]

Ha, wow. Brutal. If it was just the ARM builds that were queued for a long time, it's perhaps worth noting that Cirrus' ARM containers run on AWS EKS whereas e.g. FreeBSD runs on Google Compute Engine; perhaps there was some AWS-specific service interruption that caused the massive delays. You could try again and see if it happens again. If it does, it could be that Cirrus' EKS cluster has a global limit on jobs and the delays are a sign that unrelated OSS repos actually do compete for resources, in which case my assumption would be wrong.