Bug Report
Description
The GitHub publish flow creates and publishes the release first, then uploads distribution assets in a separate request. GitHub's immutable releases freeze a release's assets the moment it is published, so that second upload now fails:
HTTPError: 422 Client Error: Unprocessable Entity
Cannot upload assets to an immutable release
Any org that enables immutable releases hits this. It is not opt-in per repo — an org admin can turn it on for every repo at once, which is what happened to us.
Impact
The releases still get created, but with zero assets, and they can never be backfilled because they are immutable. Three of our releases published empty before we caught it.
This stayed silent for weeks: PSR swallowed the asset-upload error until #1395 was fixed in v10.6.0. After that fix the 422 surfaces as a hard failure, which is how we found it.
Reproduction
- Enable immutable releases on the org (or repo).
- Run the PSR GitHub Action with asset upload enabled (
upload_to_release / dists attached).
- The publish step fails at asset upload with
422 Cannot upload assets to an immutable release.
Root cause
Immutable releases require assets to be attached while the release is still a draft, then published. PSR publishes first and uploads after, which is the exact opposite order.
Workaround
We moved release creation out of PSR (openedx/sample-plugin#57):
vcs_release: "false" — PSR still tags, pushes, and builds, but does not create the release.
- A
gh release create step creates the release as a draft, uploads the dists, then publishes — the order immutable releases require.
- PSR's generated notes are reused via the
release_notes output, so the release body is unchanged.
Proposed fix
Native draft-first support would remove the need for the external step. This is exactly what #1193 requests — filing separately because this is a breakage on immutable-release orgs, not a convenience feature, and #1193 does not mention immutability. Resolving #1193 would likely resolve this too.
Implementation note: a native fix must span both commands, not just create_release. The distributions that fail to upload are attached in the separate publish step (upload_dists → upload_release_asset), which runs after the release is already published. So the release created by version must stay a draft until after publish uploads the dists, and only then be published — reordering create_release alone does not cover the failing path.
Bug Report
Description
The GitHub publish flow creates and publishes the release first, then uploads distribution assets in a separate request. GitHub's immutable releases freeze a release's assets the moment it is published, so that second upload now fails:
Any org that enables immutable releases hits this. It is not opt-in per repo — an org admin can turn it on for every repo at once, which is what happened to us.
Impact
The releases still get created, but with zero assets, and they can never be backfilled because they are immutable. Three of our releases published empty before we caught it.
This stayed silent for weeks: PSR swallowed the asset-upload error until #1395 was fixed in v10.6.0. After that fix the
422surfaces as a hard failure, which is how we found it.Reproduction
upload_to_release/ dists attached).422 Cannot upload assets to an immutable release.Root cause
Immutable releases require assets to be attached while the release is still a draft, then published. PSR publishes first and uploads after, which is the exact opposite order.
Workaround
We moved release creation out of PSR (openedx/sample-plugin#57):
vcs_release: "false"— PSR still tags, pushes, and builds, but does not create the release.gh release createstep creates the release as a draft, uploads the dists, then publishes — the order immutable releases require.release_notesoutput, so the release body is unchanged.Proposed fix
Native draft-first support would remove the need for the external step. This is exactly what #1193 requests — filing separately because this is a breakage on immutable-release orgs, not a convenience feature, and #1193 does not mention immutability. Resolving #1193 would likely resolve this too.