build: attach release assets before publishing the release by feanil · Pull Request #57 · openedx/sample-plugin

feanil · 2026-08-25T14:47:58Z

What happened

The v3.7.1 release run failed at Publish | Upload to GitHub Release Assets:

HTTPError: 422 Client Error: Unprocessable Entity for url:
https://uploads.github.com/repos/openedx/sample-plugin/releases/376463625/assets?name=openedx_plugin_sample-3.7.1.tar.gz
Failed to upload asset 'dist/openedx_plugin_sample-3.7.1.tar.gz' to release (HTTP 422)

Root cause

The openedx org now has immutable releases enabled, which freezes a release's assets the moment the release is published. Our flow published the release first and uploaded the distributions in a separate step afterwards, which GitHub now rejects with Cannot upload assets to an immutable release.

The immutable flag on our releases lines up exactly with when assets stopped appearing:

tag	immutable	assets
v3.7.1	true	0
v3.7.0	true	0
v3.6.1	true	0
v3.6.0	false	2

So this has been broken since v3.6.1 (2026-07-15), but the job stayed green because python-semantic-release swallowed asset upload errors until v10.6.0 fixed that. Bumping to v10.6.1 in #56 didn't break anything — it surfaced a pre-existing failure. The patch_tags = [..., "build"] addition in that same PR is why the path got exercised immediately, which is exactly what it was added for.

The fix

gh release create creates the release as a draft, uploads the assets, and only then publishes it — the sequence immutable releases require. So:

vcs_release: "false" on the python-semantic-release step, so it still tags, pushes and builds, but doesn't create the release
publish-action is replaced by a gh release create step that passes the dists as arguments
PSR's generated notes are reused via the release_notes output, so the release body is unchanged

Second commit drops OPENEDX_SEMANTIC_RELEASE_GITHUB_TOKEN in favour of the default GITHUB_TOKEN. That PAT was added in bed319c so PSR could push the changelog commit past branch protection on main; 53c8f3f then turned the changelog off, so PSR only pushes a tag now (No local changes to add to any commit) and never writes to the protected branch. Tag and release creation are both covered by the contents: write permission the job already grants, and the repo has no tag protection rules or rulesets to bypass.

Verified

Draft-first has been gh release create's behaviour since at least v2.20.0, so this doesn't depend on a recent gh on the runner
released and release_notes are both set before the make_vcs_release branch in PSR's version.py, so they survive vcs_release: "false"
Release notes containing backticks, $(...) or quotes pass through unexpanded (env var + printf '%s' + --notes-file)

The end-to-end behaviour can only be tested by publishing a real release. Since this is a build: commit, merging it releases 3.7.2 and validates itself.

Follow-ups, not in this PR

3.7.1 never reached PyPI or npm. The failing step aborted the rest of the job, so the artifact upload and all three publish jobs were skipped. Re-running won't help — the tag exists, so PSR would report released=false. Letting 3.7.2 carry it is the plan; PyPI would skip 3.7.1.
v3.6.1, v3.7.0 and v3.7.1 are permanently asset-less. They're immutable, so they can't be backfilled.
An upstream issue for python-semantic-release is drafted; there's no existing report for this.

codecov · 2026-08-25T14:50:04Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.04%. Comparing base (43d749c) to head (2bb4364).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #57   +/-   ##
=======================================
  Coverage   93.04%   93.04%           
=======================================
  Files          16       16           
  Lines         503      503           
  Branches       18       18           
=======================================
  Hits          468      468           
  Misses         24       24           
  Partials       11       11

Flag	Coverage Δ
unittests	`93.04% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

The openedx org now has immutable releases enabled, which freezes a release's assets at the moment the release is published. Our flow created and published the release with python-semantic-release and then uploaded the distributions in a separate step, so those uploads now fail with "HTTP 422: Cannot upload assets to an immutable release". Instead, let python-semantic-release tag, push and build (vcs_release: false) and create the release ourselves with `gh release create`, which creates the release as a draft, uploads the assets, and only then publishes it. Its generated release notes are reused via the release_notes output, so the release body is unchanged. This has been broken since v3.6.1 but stayed silent until now, because python-semantic-release swallowed asset upload errors before v10.6.0. v3.6.1, v3.7.0 and v3.7.1 all published with no release assets, and they are immutable now, so they cannot be backfilled. Immutable releases: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases Silent upload failures: python-semantic-release/python-semantic-release#1395 Failing run: https://github.com/openedx/sample-plugin/actions/runs/32858608339/job/97836889093 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

OPENEDX_SEMANTIC_RELEASE_GITHUB_TOKEN was introduced in bed319c so that python-semantic-release could push the changelog commit past the branch protection rules on main. 53c8f3f then turned the changelog off, so python-semantic-release only pushes a tag now ("No local changes to add to any commit") and never writes to the protected branch. Tag creation and release creation are both covered by the `contents: write` permission this job already grants, and the repo has no tag protection rules or rulesets that the default token would need to bypass. That drops our reliance on a shared org-level PAT. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it 422s every time, which is what happened on v4.1.0 (issue #433). Matches the fix already proven and merged on openedx/sample-plugin#57: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/openedx#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/openedx#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476).

Attach release assets via a draft `gh release create` instead of python-semantic-release/publish-action, which fails with HTTP 422 once immutable releases freeze a published release's assets. Set vcs_release: "false" so semantic-release builds and tags but leaves GitHub Release creation to us, guaranteeing dists attach before publish. Also bump python-semantic-release to v10.6.2. Mirrors openedx/sample-plugin#57. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

This repo has immutable releases enabled, which freezes a release's assets the moment it's published. The old flow (main PSR step publishes the release, a separate publish-action step attaches assets afterward) can never work under that constraint -- it would 422 on the first real release. Matches the fix already proven and merged on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call.

@v7

…ase (#462) * refactor: move package to src/ layout Move edx_rest_api_client/ to src/edx_rest_api_client/ per the org-wide decision on openedx/public-engineering#506 (2026-07-15): src/ layout is in scope for this modernization cycle so that editable installs resolve correctly under tools like mypy (see https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/). Update setup.py, .coveragerc, and tox.ini to reference the new path so the repo remains buildable/testable with the existing pip-based tooling until pyproject.toml formalizes the src/ layout in the next commit. * feat: consolidate package metadata into pyproject.toml Replace setup.py with PEP 621 static metadata in pyproject.toml: - name, description, classifiers, dependencies as a static list - SPDX license expression + license-files (PEP 639) - setuptools-scm for git-tag-derived versioning (dynamic version) - setuptools packages.find configured for the src/ layout - coverage configuration moved from .coveragerc into [tool.coverage.*] Remove the hardcoded __version__.py module; __version__ is now read via importlib.metadata at runtime (falls back silently if the package isn't installed), so it can no longer go stale relative to the git tag that setuptools-scm derives the build version from. * feat: switch dependency management from pip-compile to uv - Add PEP 735 [dependency-groups] (test-base, test, django42, quality, ci, dev) to pyproject.toml, with a Django 42/52 version matrix via [tool.uv].conflicts - Add [tool.edx_lint].uv_constraints and generate [tool.uv].constraint-dependencies via `edx_lint write_uv_constraints` - Generate and commit uv.lock - Delete requirements/ (pip-compile inputs/outputs); drop the now-stale references in MANIFEST.in - tox.ini: use tox-uv's uv-venv-lock-runner and dependency_groups instead of deps/-r requirements files - Makefile: requirements/test/upgrade targets now use uv sync/uv run tox/uv lock instead of pip-compile and pip-sync - CI: use astral-sh/setup-uv (SHA-pinned) instead of a separate actions/setup-python + pip install step; run tests via `uv run tox`; name matrix jobs by toxenv; add contents: read permissions and fetch-depth: 0 (so setuptools-scm can see tags); add a workflow_call trigger so release.yml can reuse this workflow * feat: add semantic-release and commitlint workflows - Add [tool.semantic_release] to pyproject.toml (build via `python -m build` with SETUPTOOLS_SCM_PRETEND_VERSION; major_on_zero = false, allow_zero_version = true) - Add release.yml: runs CI via workflow_call, then python-semantic-release cuts the release and publishes to PyPI via OIDC trusted publishing (id-token: write, no stored credentials). Actions are pinned to plain version tags (matching openedx/XBlock's production release.yml) except pypa/gh-action-pypi-publish, which is pinned to its verified commit SHA because @release/v1 is a floating branch, not a tag (root cause of a real production failure in xblocks-core's release run) - Remove publish_pypi.yml: it published on `push: tags` using a stored PYPI_UPLOAD_TOKEN and an unpinned @release/v1 ref; once semantic-release starts pushing version tags this would race with release.yml's OIDC-based publish for the same version - commitlint.yml already existed and needed no changes Pre-flight check: latest git tag v7.0.0 matches the actual latest version on PyPI, so the first semantic-release run will compute a correct next version rather than a stale/lower one. * feat: enable python-semantic-release changelog generation changelog: "false" was blindly copied from the sample-plugin reference template in release.yml with no ticket ever requiring it -- CHANGELOG.rst was never deleted and is still hand-maintained. Wire up PSR to update it automatically going forward instead of disabling it outright. - Remove changelog: "false" from release.yml's python-semantic-release step - Add [tool.semantic_release.changelog] (mode = "update", insertion_flag) and [tool.semantic_release.changelog.default_templates] (CHANGELOG.rst, rst) to pyproject.toml - Add the ".. changelog-insertion-marker" line to the top of CHANGELOG.rst so PSR's update mode inserts new version sections above it, leaving the existing hand-written history untouched - Set tag_format = "v{version}" explicitly to match this repo's actual tag convention (v7.0.0, v6.2.0, ...) rather than relying on PSR's untested default * fix: disable python-semantic-release changelog generation Set changelog: "false" on the PSR release step and remove the [tool.semantic_release.changelog] config / insertion marker. Checked against openedx/XBlock's actual production release.yml (the one repo in this effort that has cut real automated releases) -- every run passes changelog: false and invokes `semantic-release -v version --no-changelog`, and the repo has zero github-actions[bot] commits ever. The auto-changelog config this migration previously added was only ever verified via a local dry-run prototype, never against a real release. feanil flagged the same issue on openedx/DoneXBlock#388: "I thought we were not going to add changelogs since they can't be updated by python-semantic-release the way we have it setup." * fix: drop tox from Makefile's quality target Inline tox.ini's [testenv:quality] commands via uv run/uv sync instead of shelling out to `uv run tox -e quality`, matching the no-tox-in- Makefile convention already used elsewhere. tox.ini itself is untouched. * fix: create GitHub release with assets attached, not after publish This repo has immutable releases enabled, which freezes a release's assets the moment it's published. Previously this workflow didn't even attempt to attach dist files to the GitHub release (relying only on the actions/upload-artifact -> download-artifact path for PyPI publish), so every release shipped with an empty GitHub Release page. Matches the fix already proven on openedx/sample-plugin#57 and validated end-to-end on openedx/event-tracking#434: build without publishing (vcs_release: false), then create the release with dist/* attached in one gh release create call. Not adding the separate gitpython/uv workaround from event-tracking#435/#436 here -- these PRs won't merge until upstream python-semantic-release fixes the GitPython 3.1.60 break (python-semantic-release/python-semantic-release#1476). * fix: bring release.yml into conformance with sample-plugin gold standard Several action pins had drifted from openedx/sample-plugin's verified release.yml (the org's Phase 3 conformance reference for openedx/public-engineering#506): - actions/checkout was pinned to v6.0.2 (de0fac2...); bump to the verified v7.0.1 SHA (3d3c42e...). - The release job's checkout also carried fetch-depth: 0, which python-semantic-release never needs (it auto-deepens a shallow clone itself before evaluating version history) and which sample-plugin's reference does not set. - python-semantic-release and the upload/download-artifact steps were pinned to bare floating tags (@v10.6.1, @v7, @v8) instead of pinned commit SHAs -- exactly the kind of unpinned action this org's modernization effort is meant to close off. Pinned to verified SHAs for the current versions (v10.6.2, v7.0.1, v8.0.1 respectively). - pypa/gh-action-pypi-publish was correctly SHA-pinned but one version behind (v1.14.1); bumped to the verified v1.14.2 SHA. - The upload-artifact step was missing if-no-files-found: error, so a build that silently produced no dist/ files would upload nothing and the workflow would report success anyway. - publish_to_pypi's `if:` was missing the github.ref_name == 'master' guard sample-plugin's reference uses alongside needs.release.outputs.released == 'true'. Every SHA above was independently re-verified against its action's own commit and tag history (resolving annotated tags one level to their commit) rather than trusted at face value, per this org's history of fabricated/swapped SHAs in this exact file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: drop unneeded fetch-depth: 0 from ci.yml checkout setuptools-scm (used for this package's dynamic version) has fallback_version = "0.0.0" configured in pyproject.toml, so a shallow clone without tag history never fails the build -- it just resolves to the fallback version. Nothing downstream parses or splits __version__ (checked src/edx_rest_api_client/client.py and its tests): it's only ever interpolated as a plain string into the User-Agent header. sample-plugin's own backend-ci.yml does not set fetch-depth: 0 either. Same reasoning already confirmed safe on opaque-keys#461. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: address review feedback (author metadata, stray classifier) - Author metadata matches the org-wide convention used elsewhere in this migration (Open edX Project / oscm@openedx.org). - Drop the Python 3.11 classifier -- CI has only ever tested 3.12, both before and after this migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: remove unnecessary try/except around __version__ (not present pre-migration) * fix: remove fail-fast: false (not present pre-migration) --------- Co-authored-by: irfanuddinahmad <irfanuddinahmad@users.noreply.github.com> Co-authored-by: Irfan Ahmad <irfan.ahmad@A006-01919.local> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Usama Sadiq <usama7274@gmail.com>

feanil and others added 2 commits August 25, 2026 11:05

feanil force-pushed the feanil/fix_immutable_release_assets branch from 012edf6 to 2bb4364 Compare August 25, 2026 15:06

feanil marked this pull request as ready for review August 25, 2026 15:08

feanil merged commit 5d5da4e into main Aug 25, 2026
9 checks passed

feanil deleted the feanil/fix_immutable_release_assets branch August 25, 2026 15:08

feanil mentioned this pull request Aug 26, 2026

build: CI, packaging and release maintenance #58

Merged

irfanuddinahmad mentioned this pull request Aug 27, 2026

release.yml: asset upload fails (422), v4.1.0 has no release assets, PyPI stuck at 4.0.2 openedx/event-tracking#433

Closed

farhan mentioned this pull request Aug 27, 2026

GitHub publish fails with 422 on orgs with immutable releases enabled python-semantic-release/python-semantic-release#1478

Open

salman2013 mentioned this pull request Aug 31, 2026

feat: modernize Python tooling to uv + pyproject.toml + semantic-release openedx/openedx-core#704

Open

This was referenced Sep 1, 2026

build: align release workflow with sample-plugin standard openedx/xblocks-extra#77

Merged

build: align release workflow with sample-plugin standard openedx/xblocks-core#297

Merged

farhan mentioned this pull request Sep 1, 2026

fix: make release workflow compatible with immutable releases openedx/XBlock#949

Merged

farhan mentioned this pull request Sep 14, 2026

feat: modernize Python tooling (uv, pyproject.toml, src layout, semantic-release) openedx/xblock-skill-tagging#61

Open

4 tasks

Navigation Menu

build: attach release assets before publishing the release - #57

build: attach release assets before publishing the release#57
feanil merged 2 commits into
mainfrom
feanil/fix_immutable_release_assets

feanil commented Aug 25, 2026

Uh oh!

codecov Bot commented Aug 25, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

feanil commented Aug 25, 2026

What happened

Root cause

The fix

Verified

Follow-ups, not in this PR

Uh oh!

codecov Bot commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

codecov Bot commented Aug 25, 2026 •

edited

Loading