I think we could also rename most of the "library"/"libraries"/"LIBRARY" to "stdlib"/"STDLIB" and it'd be clearer this is running on the standard library and not any third-party library code.

I agree with this, we can change most of our uses to "stdlib" within this PR except foross-fuzz-project-name. I can handle that in a separate PR since we'll have to wait for OSS-Fuzz maintainers to rename the project.

Thanks@StanFromIreland and@hugovk for the reviews! I've moved to a reusable workflows approach. I'll try pushing a commit modifying one of the libraries to check that the workflow fires correctly.

(I resolved the conflict)

@webknjaz I'm not sure why actionlint is refusing thecontains([...], 'true') syntax used, checking on theallowed function definitions it seemed like this would be allowed?

With the latest commit we got a run, but the values ofoss-fuzz-project-name andsanitizer aren't being forwarded (the reusable workflow is seeing an empty string?) from the job matrix into the reusable workflow. I don't think I'm doing anything different than any of the other reusable workflows that use a matrix and forward parameters?

@webknjaz I'm not sure why actionlint is refusing thecontains([...], 'true') syntax used, checking on theallowed function definitions it seemed like this would be allowed?

Not sure. Might be a bug in actionlint. Or maybe I misunderstood that this'd work from the docs 🤷‍♂️

With the latest commit we got a run, but the values ofoss-fuzz-project-name andsanitizer aren't being forwarded (the reusable workflow is seeing an empty string?) from the job matrix into the reusable workflow. I don't think I'm doing anything different than any of the other reusable workflows that use a matrix and forward parameters?

Sounds like maybe I messed up the suggested conditionals or something. I'll double-check the current diff.

One more thing — in general, it's a good idea to keep the CI infra the same (at least structurally) across branches since this will reduce conflicts when backporting more important changes. So this will need to be backported if possible. Either partially or, if there's no problems — in full. The backwards compat considerations would almost never apply to the CI infra the same way it'd apply to the user-facing changes.

A brief note on CI time. These three jobs take about 22 minutes, which is fine:

• CIFuzz / python3-libraries (undefined) 22m 36s
• CIFuzz / python3-libraries (address) 20m 38s
• CIFuzz / python3-libraries (memory) 22m 14s

https://github.com/python/cpython/actions/runs/21006197138/usage

We have a few other jobs taking around this long, like Android and iOS and some Windows ones, with one free-threaded Windows being the bottleneck at 32 mins.

Just something to keep an eye on.

Thanks@sethmlarson for the PR, and@hugovk for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

Sorry,@sethmlarson and@hugovk, I could not cleanly backport this to3.14 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker edeebe22cb6bff3df4196bef3dcbdc7044f54df6 3.14

Sorry,@sethmlarson and@hugovk, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker edeebe22cb6bff3df4196bef3dcbdc7044f54df6 3.13

@hugovk I can work on creating backports. Thanks for the reviews, everyone!

GH-143912 is a backport of this pull request to the3.14 branch.

GH-143915 is a backport of this pull request to the3.13 branch.

A brief note on CI time. These three jobs take about 22 minutes, which is fine:

Sometimes... This run is over an hour:https://github.com/python/cpython/actions/runs/21520243325/job/62009161712?pr=144293