Test PR: pin PSR tag_format and document release remediation

[farhan]

Problem

Automated releases are not reaching PyPI — the package is stuck at 0.4.3, while the repo has stray tags/GitHub Releases for v0.4.4 and v0.4.5 that were never published. Two independent root causes:

1. Tag-format mismatch (versioning). python-semantic-release (PSR) determines the last released version by reading git tags only — never PyPI. It inverts tag_format into a regex (default v{version} → ^v(?P<version>.+)$) and silently discards every tag that does not match. This repo's entire real history uses bare tags (0.1.0 … 0.4.3), so a default-config PSR ignores all of it, restarts from 0.0.0, and either refuses to release (No release will be made, 0.1.0 has already been released) or invents versions that never existed on PyPI.

2. HTTP 422 on GitHub Release asset upload (artifacts). In the release job, the Upload to GitHub Release Assets step (publish-action → upload_dists) fails with 422 Unprocessable Entity for both the .whl and .tar.gz. That kills the job before actions/upload-artifact, so the distribution never reaches artifact storage and publish_to_pypi is skipped (the - in the run summary — skipped, not failed).

What this PR changes

1. Pins tag_format = "v{version}" in [tool.semantic_release] with a comment documenting that a matching baseline tag must exist. Makes the convention explicit so nobody assumes bare tags work, and pairs with the operational fix below.
2. Makes the GitHub Release asset upload non-blocking (continue-on-error: true on the Upload to GitHub Release Assets step). That step 422s and, because publish_to_pypi has needs: release, its failure cascades and skips PyPI. Attaching dists to the GitHub Release is cosmetic — PyPI publishes from the uploaded artifact via OIDC — so this unblocks the PyPI path regardless of the 422's root cause.

This PR still does not fully close the loop on its own — the versioning fix is mostly operational (tags), and the 422 itself is only neutralized, not root-caused. The full checklist is below.

Remaining steps

Versioning (do first)

• Publish the baseline tag PSR can recognize, on the commit released as 0.4.3 (3be8beb):

  git tag v0.4.3 3be8beb
  git push origin v0.4.3
  

• Delete the stray tags + GitHub Releases that never reached PyPI (otherwise PSR bumps from 0.4.5 → 0.4.6, skipping numbers):

  for t in v0.1.0 v0.4.4 v0.4.5; do
    gh release delete "$t" --repo openedx/forum --yes --cleanup-tag
  done
  

• Confirm PSR now sees v0.4.3 as the latest release (a fix: commit should compute 0.4.4).

Artifacts — the 422 (the actual PyPI blocker)

• Neutralized in this PR — continue-on-error: true on the asset-upload step so the 422 can no longer fail the job or skip publish_to_pypi. Confirmed from PSR source that this is safe: version attaches only the config assets list (empty here), so this step is the only thing uploading dists and is off the PyPI critical path.
• Root-cause (follow-up): reproduce to capture the stripped 422 body (a throwaway release + gh release upload / curl -v with GITHUB_TOKEN prints the full JSON), then either switch the step to idempotent gh release upload "$TAG" dist/* --clobber or bump the pinned PSR/publish-action version. Tracks whether GitHub-Release assets get attached at all — not a PyPI blocker anymore.

Verify end-to-end

• Land a fix: commit on master → confirm PSR computes 0.4.4, the asset upload succeeds, publish_to_pypi runs (not skipped), and 0.4.4 appears on PyPI.

Verification tooling

The modernize-python-repos skill now has two versioning guards that catch this class of failure:

• Test 245 — offline: the latest release tag must match tag_format (else emits SUGGEST-TAG).
• Test 246 — ground-truth: a tag_format-matching tag must exist for the version currently on PyPI. Run against this repo today it fails with SUGGEST-TAG: v0.4.3.

🤖 Generated with Claude Code