release.yml: asset upload fails (422), v4.1.0 has no release assets, PyPI stuck at 4.0.2

[irfanuddinahmad]

`release.yml` (added in #425, the pip→uv/python-semantic-release migration) ran for the first time on merge and got partway through before failing.

What happened (run: https://github.com/openedx/event-tracking/actions/runs/32368097699):

1. The "Python Semantic Release" step (using `OPENEDX_SEMANTIC_RELEASE_GITHUB_TOKEN`) bumped the version, built the dists, tagged `v4.1.0`, and created the GitHub release. Succeeded.
2. The "Publish | Upload to GitHub Release Assets" step (`publish-action`, using the default `GITHUB_TOKEN`) then failed to attach either dist file to that release — `422 Unprocessable Entity` on both.
3. Because that step failed, `publish_to_pypi` never ran.

Current state: release `v4.1.0` exists with zero assets; PyPI's `event-tracking` is still at 4.0.2.

This won't self-heal — every later run just sees tag `v4.1.0` already exists and no-ops, so nothing will retry the upload/publish.

[irfanuddinahmad]

Root cause: This repo (like several others in the org) has GitHub's immutable releases enabled — once a release is published, its assets are frozen, so the old two-step flow (main PSR step publishes the release, then a separate publish-action step tries to attach dist files afterward) can never work; it'll always 422.

Confirmed by an identical failure on openedx/sample-plugin, fixed and merged (feanil-approved) in openedx/sample-plugin#57: set vcs_release: "false" on the main PSR step (so it only bumps/tags/builds, doesn't publish), then create the release with gh release create ... dist/* in one step so assets attach before the release goes live.

Still need someone with PyPI publish access for event-tracking to backfill 4.1.0 once this is fixed, since automation permanently gave up on that version.

[bmtcril]

@irfanuddinahmad once we have a new version built and released I'll yank 4.1.0 just to keep things consistent

[irfanuddinahmad]

The fix is up: #434 — CI green, ready to merge. Once it merges, that commit's own fix: type will trigger a real release (4.1.1) that exercises the corrected pipeline end-to-end. @bmtcril, this is the one to merge for the new version before yanking 4.1.0.

[bmtcril]

Looks like it didn't quite work, though logs aren't being helpful:

https://github.com/openedx/event-tracking/actions/runs/33070448676/job/98511159329

[irfanuddinahmad]

That failure is unrelated to #434's fix -- it's a separate, unrelated upstream break: python-semantic-release's GitHub Action builds its own Docker image fresh on every run and pins gitpython~=3.0 (unbounded). GitPython 3.1.60 (released 2026-08-25, two days ago) removed Actor.name_email_regex, which PSR's config loader reads unconditionally, so every fresh build of the action's image now fails with that AttributeError -- regardless of which PSR version is pinned. Tracked upstream: python-semantic-release/python-semantic-release#1476, fix open in #1477 but not released yet.

Fix is up: #435 -- runs PSR ourselves via uv instead of the Docker action, so we can pin gitpython<3.1.60 ourselves. CI green, verified locally in --noop mode first. @bmtcril, this is the one to merge (after #434, which is already in) to get the real release out.

[bmtcril]

@irfanuddinahmad Pretty close, looks like we just need to install pip. This run was also a lot faster (13s to failure vs ~2 mins with the docker image) so unless there's a pressing reason to use the image it might be better just to continue to use the uv version going forward.

[irfanuddinahmad]

Thanks @bmtcril
#436 created
#435 got past the GitPython crash but then hit a new failure at the build step -- PSR's build_command shelled out to pip install build, which doesn't exist in uv's ephemeral venvs. Switched build_command itself to uv build instead of reintroducing pip. Verified locally through the real uvx-wrapped PSR execution (not just uv build standalone) -- produces the correct dist/ artifacts. CI green, ready to merge.

[bmtcril]

Looks good, 4.1.1 is released and confirmed on PyPI. I've got a note to yank 4.1.0 next week, just in case anything pulled it in to requirements via GH. Seems unlikely, though.

Thanks for the fast turnaround with fixes!