MAINT, CI: Cirrus resource usage changes coming September 1st

[tylerjereddy]

This isn't particularly surprising for those of us who were around for a similar transition for Travis CI, but here is the relevant post: https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/

This is causing some upstream activity in NumPy/SciPy, mostly to try to use Cirrus more sparingly/efficiently, I guess we can try to follow what they do if it is practical. Of course, reshuffling CI services gets a bit exhausting!

[IAlibay]

Today I found out there's no melting face emoji on github.

That's a pain.. thanks for the heads up @tylerjereddy.

[IAlibay]

We use roughly somewhere between 80 and 100 compute credits per month.

Back of the envelope calculation -

With the announced reduction in costs:

20 compute credits is 1000 minutes of arm64-osx CPU time, and 3 compute credits is 1000 minutes of aarch64-linux CPU time.

We use ~ 6 m * 4 CPUs = 24 CPU minutes of macos-arm64 time and ~ 10m * 8 CPU = 80 CPU minutes of linux aarch64 per trigger. So that's roughly 0.48 compute credits per macos-arm64 job, and 0.24 credits per linux aarch64 jobs, i.e. a total of 0.72 compute credits per trigger.

This means that we can roughly run CI 31 time per month before we run out. On top of this we also need to use it for deployments which probably uses ~ 10 or so credits.

[IAlibay]

My suggestion is just to switch cirrus CI to a cron trigger that goes twice a week, so 8 times a month. That leaves us enough credits in case we need to do a release (assuming we don't have to release more than a couple times in a month).

[IAlibay]

I'm putting this in as a 2.6.0 milestone since we should be aiming for a release by mid-August.

If anyone sees / hears of alternate osx-arm64 CI services please do pitch in here!

[IAlibay]

Cron job is up and running fine. We can go ahead and kill off conventional CI by the end of the month.

TODO:

• Disable standard job execution
• Add badge for Cirrus Cron jobs so we know when it goes down

[IAlibay]

For context here are our wheel build timings:

• 08:24 for linux aarch64
• 03:44 for macos-arm64
• 01:05 for wheel uploading (linux)

We should be fine to do a few deployments a month (we're probably going to use < 0.4 credits per deployment).

[IAlibay]

@tylerjereddy something I just saw - looks like the blog post has been updated and the number of free credits has been increased from 20 to 50 per month. At least for MDA, this nearly makes running CI regularly affordable.

[tylerjereddy]

@IAlibay @orbeckst also of possible interest: actions/runner-images#8439

[IAlibay]

Thanks @tylerjereddy !

[radeva]

@IAlibay @tylerjereddy If you switch to GitHub Actions, you can try FlyCI's M1 and M2 runners. They are on average 2x faster and 2x cheaper than GitHub's AND we have a free tier for OSS projects (see below).

Install Instructions

1. Install FlyCI app and
2. Easily replace one line of code and start using FlyCI runners:

jobs:
 ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
   steps:
   - name: 👀 Checkout repo
     uses: actions/checkout@v4

500 mins/month Free for Public Repos

Since your repo is public, FlyCI offers 500 mins/month of free M1 runner usage with the flyci-macos-large-latest-m1 runner for public projects.

Don't hesitate to contact us in case the free tier doesn't suit your needs or you experience any issues with the runners. Our team is here to support you!

Best Regards,
Veselina Radeva
Product Manager at FlyCI