FreeBSD gets a new "Cirrus-CI" GitHub Action job and a new buildbot

brettcannon · September 13, 2023, 11:26pm

Please see the above conversation where this was all cleared up.

vstinner · September 14, 2023, 10:45am

Yes, I would like to discuss it: I created Consider downgrading Windows 32-bit from Tier-1 to Tier-2 or Tier-3? (in Python 3.13?) topic. Let’s continue the discussion there

Note: Python 3.12 release candidate versions have Windows 32-bit installer, and @thomas confirmed me that the Python 3.12 final version will be released with a Windows 32-bit installer. If something changes, it should only occur in Python 3.13. Well, let’s continue the discussion in the topic that I created

vstinner · September 14, 2023, 10:56am

Sorry, I didn’t get if anyone knows a way to exclude "non-voting CIs from the overall PR status?

If there is no way for that, I would like to suggest disable/remove all non-voting CIs on pull requests, and only run them on the main branch (once changes are merged):

Windows x86
Azure Pipelines
FreeBSD

My concern is that these CI resources will be wasted since basically no one is going to look into these failures anymore. I already noticed that very few people pay attention to CIs and prefer to ignore all failures as “it’s not my business, the failure is not related to my exact change”. It’s the “duty of everyone” to fix the CI, which means that… nobody fix it

Hum, I don’t understand the list of GitHub Actions on the main branch: CI like Windows 64-bit or Ubuntu are not run?

I agree that only failures on Tier-1 platforms must block the workflow and prevent to merge a change which would make the CI state worse than it was

hugovk · September 14, 2023, 1:56pm

I don’t know how to do this, unless there’s some way to catch a failure and report a pass or
a skip. But that would hide the failure.

We can mark some checks as “required”, which means they must pass for the PR to be merged.

There’s a lot of overlap between Azure Pipelines and GitHub Actions. GitHub Actions is easier to use and maintain, so let’s move things over. python/cpython#105823 already removed some duplicate docs testing from AP. There’s still some unique patchcheck things in AP that should be need moving over.

Yes, they’re run under the “Tests” workflow:

It has logic to only run docs jobs if there are docs changes (for example), and only run Ubuntu, Windows, macOS CI etc if there are normal code changes (for example).

hugovk · September 14, 2023, 3:57pm

Issue for this:

github.com/python/cpython

Move Azure Pipelines CI to GitHub Actions

opened 03:54PM - 14 Sep 23 UTC

hugovk

build

GitHub Actions is easier to use and maintain. For example, GitHub Actions is mor…e popular and widely used, and so more familiar. It's easier to maintain a single system. Also core devs can restart failed GitHub Actions whereas they can't for Azure Pipelines. Both are owned by Microsoft and I believe they run on much the same infra. There's a lot of duplication of tests between Azure Pipelines and GitHub Actions. Let's remove the duplicated tests, and move the unique things over to GitHub Actions. For example, `patchcheck` is only run on AP. We might not necessarily need to port things directly over, it may be possible to replicate equivalent checks in another way, possible with a pre-commit or Ruff lint rule. Let's evaluate these separately. Related issues/PRs: * https://github.com/python/cpython/issues/109395 * https://github.com/python/cpython/pull/109400 * https://github.com/python/cpython/pull/109412 * https://github.com/python/cpython/pull/105823 * https://github.com/python/cpython/issues/84018 * https://github.com/python/cpython/pull/18818 ### Linked PRs * gh-109452 * gh-109453 * gh-109459 * gh-109519 * gh-109520 * gh-109535 * gh-109536 * gh-109569 * gh-109623 * gh-109624 * gh-109854 * gh-109890 * gh-109891 * gh-109895 * gh-110594 * gh-110595 * gh-110633 * gh-110636 * gh-110640 * gh-110641 * gh-110726 * gh-110730

hugovk · September 15, 2023, 8:07am

We’ve hit the monthly limit after 9 days:

Failed to start an instance: FAILED_PRECONDITION: Monthly free compute limit exceeded!

This was mentioned in the issue:

Cirrus-CI might be an alternative, apparently, given this issue and relative PR, although I’m not familiar with them. Recently they introduced a limit to free usage which Python would likely exceed. So someone would have to get in touch and ask for additional resources for Python.

From that blog post:

Starting September 1st 2023, there will be an upper monthly limit on free usage equal to 50 compute credits (which is equal to a little over 16,000 CPU-minutes for Linux tasks).

Cirrus CI shows:

Your current compute credits balance: -0.39

Credits used: 61
CPU hours used: 335

Can we get the limit increased?

vstinner · September 15, 2023, 4:05pm

I contacted Cirrus CI company to ask them if they would be interested to sponsor the Python project.

Since FreeBSD is only a Tier-3 platform, I don’t want to ask the PSF to cover the cost of such service for now.

Until a resolution is found, I wrote gh-91960: Disable Cirrus CI for now by vstinner · Pull Request #109457 · python/cpython · GitHub to disable the job for now.

vstinner · September 22, 2023, 4:42pm

The disabled the Cirrus CI FreeBSD job for now.

In the meanwhile, I fixed the FreeBSD 13 buildbot.I fixed the last failing test, test_tarfile with the help of Davide Rizzo.

The builder was green 7 builds in a row, it’s time to take a screenshot

Note: Python 3.12 is awaiting the test_tarfile fix to be merged which will happen in ~10 days, after Python 3.12.0 final release.