Please see the above conversation where this was all cleared up.
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
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
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
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:
Issue for this:
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?
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.
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.