This makes sense; but it also raises an eyebrow because this is something that no other platform has needed. I presume this is because no other platform that is generating binary artefacts is doing so with the tooling in release-tools?

@webknjaz, do you have any thougts here?

I'll take a look, thanks for tagging.

@mhsmith so I've tried to understand the context and this justtification didn't make sense to me.

It is perfectly possible to call reusable workflows from other repositories (in fact, this is what I'm building my reusable-tox.yml ecosystem on).

My understanding is that this is meant to be used in https://github.com/python/release-tools/blob/698deaf2ebff433a6ab9d4b5ded97a40fce109a1/.github/workflows/source-and-docs-release.yml, right?

In any case, I've been moving away from composite actions in favor of reusable workflows. This is because composite actions (or any actions for that matter) are represented as a single step in job runs. And it's rather difficult to inspect what actions are doing. So from the troubleshooting perspective, I'd strongly advise against composite actions.

It is important to make every step visible and transparent. And if you follow the practice I established with reusable workflows as modules in here, this is definitely possible.

I started with in-repo "modules" two years ago because I was solving the problem of making it possible to collect all the job statuses in a single check (for branch protection). This wasn't because it's somehow impossible to host them externally. This was just not something necessary for that purpose.

@encukou I've actually been meaning to ask if there's any workflows that are being duplicated in the python org. If yes, it'd make sense to host them in a shared repository. This could be a .github repo or even that release-tools one (although, I don't know if it makes semantic sense). This is a separate question, though.

That said, if you've faced any confusion or need help adapting this to be a reusable workflow, just let me know where you're stuck. I can help you navigate this or just rewrite it for you.

This makes sense; but it also raises an eyebrow because this is something that no other platform has needed. I presume this is because no other platform that is generating binary artefacts is doing so with the tooling in release-tools?

Right now, release-tools only creates source zips and docs artifacts. See https://github.com/python/release-tools/actions/runs/16450411678 for 3.14 RC2.

The Windows artifacts are built in Azure Pipelines, here's RC2. And Ned builds the macOS artifacts. (release-tools later takes these Windows and macOS artifacts and signs and uploads them.)

We're hoping to build the macOS artifacts using CI in the near future, so what we decide here may help inform how to do that to :)

My understanding is that this is meant to be used in python/release-tools@698deaf/.github/workflows/source-and-docs-release.yml, right?

Yes, see https://github.com/python/release-tools/pull/265/files#diff-4d14704b6b88fb06db888f96c03a8e9b3a5e07a4ee566d97d4111b2c05210e84R220.

One thing I'd like to see is CI in this repo to check Android builds okay, so we don't get caught ought on release day because we only build in release-tools.

This happened in 3.14 RC1 with the plaintext docs, which had broken back in April or so, but RC1 is the first prerelease to build docs and we hadn't caught it here.

One deciding factor for whether we have stuff over here (via composite actions or something else) might be how much difference there'll be between different versions (3.14, 3.15, etc). If a lot, we might not want it all in release-tools and would benefit from versioning things in branches over here.

On the other hand, the docs build is also versioned in branches here, release-tools CI calls a make dist command in this repo.

On the other hand, the docs build is also versioned in branches here, release-tools CI calls a make dist command in this repo.

That's more or less the way I've been trying to suggest.