Release for Python 3.8.19, 3.9.19, and 3.10.14

[indygreg]

CPython 3.8.19, 3.9.19, and 3.10.14 were released on March 19, 2024 and contain security fixes. We should upgrade and get a release out the door with these versions.

[zanieb]

I'd be interested in doing some work on this (sounds like @charliermarsh might do it before me though).

[charliermarsh]

I'll do the download bump now to start.

[indygreg]

@charliermarsh you are a collaborator on the repo now and the latest commit on main (d09ff921d92d6da8d8a608eaa850dc8c0f638194) should be appropriate for a release (assuming CI passes). You should be able to run just release $(cat /path/to/github/token) d09ff921d92d6da8d8a608eaa850dc8c0f638194 20240414 to perform a release.

You have my blessing to run this command.

The release should be created as pre-release by default. Please make an attempt to populate the release notes. Then @ me here once done so I can look at things and we can promote the release.

If you run into release pipeline regressions during the release (not uncommon!), I usually just hack up code locally to get it to pass, push to main [via PR], then run the release automation from the fixed commit, targeting an older commit (so you don't have to wait for GitHub Actions to finish before releasing).

[charliermarsh]

Great, thanks @indygreg! I'll give this a try today.

[charliermarsh]

Tried but failed with:

downloading cpython-3.11-x86_64-apple-darwin-debug
downloading cpython-3.11-aarch64-apple-darwin-pgo
downloading cpython-3.11-aarch64-apple-darwin-debug
downloading cpython-3.12-aarch64-apple-darwin-debug
downloading cpython-3.11-aarch64-apple-darwin-pgo+lto
downloading cpython-3.11-x86_64-apple-darwin-pgo
downloading cpython-3.12-aarch64-apple-darwin-pgo
downloading cpython-3.8-aarch64-apple-darwin-pgo
downloading cpython-3.12-aarch64-apple-darwin-pgo+lto
downloading cpython-3.8-aarch64-apple-darwin-pgo+lto
downloading cpython-3.9-aarch64-apple-darwin-debug
downloading cpython-3.11-x86_64-apple-darwin-pgo+lto
downloading cpython-3.9-aarch64-apple-darwin-pgo
downloading cpython-3.10-aarch64-apple-darwin-debug
downloading cpython-3.9-aarch64-apple-darwin-pgo+lto
downloading cpython-3.12-x86_64-apple-darwin-debug
downloading cpython-3.10-aarch64-apple-darwin-pgo
downloading cpython-3.8-aarch64-apple-darwin-debug
downloading cpython-3.10-aarch64-apple-darwin-pgo+lto
downloading cpython-3.12-x86_64-apple-darwin-pgo
downloading cpython-3.8-x86_64-apple-darwin-pgo
downloading cpython-3.12-x86_64-apple-darwin-pgo+lto
downloading cpython-3.9-x86_64-apple-darwin-debug
downloading cpython-3.8-x86_64-apple-darwin-pgo+lto
Error: invalid Zip archive: Could not find central directory end
error: Recipe `release-download-distributions` failed on line 31 with exit code 1
error: Recipe `release` failed with exit code 1

Looking into it although I can't run just release as-is since the tag now exists.

[charliermarsh]

Is it possibly because the builds are all now re-running on that commit, since we created a tag for it?

[charliermarsh]

Gonna wait for those builds to complete, then re-run (skipping the tag creation step).

[indygreg]

The Rust release automation is only supposed to look at CI invocations that are done. So multiple CI runs in the same commit shouldn't be an issue. But this logic has historically been buggy.

Earlier log snippet indicates the CI artifact wasn't a zip file. Feels like an intermittent failure or we messed up artifact uploading.

[charliermarsh]

Wondering if there's something wrong with my creds because I'm seeing it consistently for different artifacts; and when I download them out-of-band, they seem to unzip without error (e.g., cpython-3.11-aarch64-apple-darwin-debug). Looking into it.

[charliermarsh]

(Creds would be odd though since I'd expect an earlier failure and my creds successfully created the Release itself.)

[charliermarsh]

Okay yeah the fetched artifact on my machine (when fetched via github.rs) is just 158 bytes. Looking at it...

[charliermarsh]

Hah, ok, the contents are just:

{"message":"You must have the actions scope to download artifacts.","documentation_url":"https://docs.github.com/rest/actions/artifacts#download-an-artifact"}

[charliermarsh]

Ok, I generated a fine-grained PAT with the Actions scope and now it's moving along nicely.

[charliermarsh]

Ok, so it looks like the shared-* Windows versions aren't being generated, and the gnueabihf hard float variants are missing too:

missing release artifact: cpython-3.10.14-armv7-unknown-linux-gnueabihf-debug-20240401T1106.tar.zst
missing release artifact: cpython-3.10.14-armv7-unknown-linux-gnueabihf-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.10.14-armv7-unknown-linux-gnueabihf-lto-20240401T1106.tar.zst
missing release artifact: cpython-3.10.14-armv7-unknown-linux-gnueabihf-noopt-20240401T1106.tar.zst
missing release artifact: cpython-3.10.14-i686-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.10.14-i686-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.10.14-x86_64-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.10.14-x86_64-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.11.9-armv7-unknown-linux-gnueabihf-debug-20240401T1106.tar.zst
missing release artifact: cpython-3.11.9-armv7-unknown-linux-gnueabihf-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.11.9-armv7-unknown-linux-gnueabihf-lto-20240401T1106.tar.zst
missing release artifact: cpython-3.11.9-armv7-unknown-linux-gnueabihf-noopt-20240401T1106.tar.zst
missing release artifact: cpython-3.11.9-i686-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.11.9-i686-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.11.9-x86_64-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.11.9-x86_64-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.12.3-armv7-unknown-linux-gnueabihf-debug-20240401T1106.tar.zst
missing release artifact: cpython-3.12.3-armv7-unknown-linux-gnueabihf-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.12.3-armv7-unknown-linux-gnueabihf-lto-20240401T1106.tar.zst
missing release artifact: cpython-3.12.3-armv7-unknown-linux-gnueabihf-noopt-20240401T1106.tar.zst
missing release artifact: cpython-3.12.3-i686-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.12.3-i686-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.12.3-x86_64-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.12.3-x86_64-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.8.19-i686-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.8.19-i686-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.8.19-x86_64-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.8.19-x86_64-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.9.19-armv7-unknown-linux-gnueabihf-debug-20240401T1106.tar.zst
missing release artifact: cpython-3.9.19-armv7-unknown-linux-gnueabihf-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.9.19-armv7-unknown-linux-gnueabihf-lto-20240401T1106.tar.zst
missing release artifact: cpython-3.9.19-armv7-unknown-linux-gnueabihf-noopt-20240401T1106.tar.zst
missing release artifact: cpython-3.9.19-i686-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.9.19-i686-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst
missing release artifact: cpython-3.9.19-x86_64-pc-windows-msvc-shared-install_only-20240401T1106.tar.gz
missing release artifact: cpython-3.9.19-x86_64-pc-windows-msvc-shared-pgo-20240401T1106.tar.zst

[charliermarsh]

(Looking into both of these.)

[charliermarsh]

Ok I believe I've debugged the shared-* issue. Just requires a small change to release.rs.

[charliermarsh]

Should be fixed in https://github.com/indygreg/python-build-standalone/pull/250. (Would you prefer to create a new release tag, or just release locally once that is merged, since it only affects the upload process and not the assets?)

[charliermarsh]

The (hopefully last?) problem I'm running into is that GitHub is rejecting my uploads:

failed to upload release artifact: {"message":"Resource not accessible by personal access token","request_id":"D96C:14B855:251187:284124:661EBE4B","documentation_url":"https://docs.github.com/rest"}

Despite giving my PAT read+write on "Contents" and even "Admin".

[indygreg]

That's just weird. So you can create a release on the repo but not upload an artifact to it? That seems like an odd permissions rift.

I want to believe different credentials are being used. It's the Rust code failing, not gh. So it must have something to do with the PAT used by Rust/just.

[charliermarsh]

Let me investigate that hypothesis. I've also tried creating fine-grained PATs with all permissions, and using a classic PAT, all with the same result.

[charliermarsh]

It seems to be using the token I provided, as far as I can tell? It's the only request that doesn't go through octobcrab though and the only request that (IIUC) is lacking representation in the semantic API.

[charliermarsh]

(Will dig into this again tonight.)

[charliermarsh]

I got this to work by creating a class PAT with every permission enabled. I'll follow up later to figure out the exact necessary combination.

[charliermarsh]

@indygreg - Okay, success, I think? I've populated the release notes but left it in draft here: https://github.com/indygreg/python-build-standalone/releases/tag/20240415

[indygreg]

I finally have some time on my desktop tonight. So I'll be taking a pass on the release notes and will likely remove the pre-release label. Thank you for your patience figuring out how to release.

Maybe a good follow-up would be to move the release automation to a parameterized GitHub Action workflow so we don't have to bother with local tokens.

[indygreg]

I just published the 20240415. Thanks again for your persistence!

[charliermarsh]

No prob, thank you for promoting! I'll think too on ways we can streamline it.