Repository navigation
🐛 fix(release): publish the GitHub release after a 403 - #295
Merged
Merged
Conversation
The publish step creates the release with gh, which needs contents: write. With contents: read the v2.4.8 run failed with HTTP 403 after the Marketplace upload had already succeeded. tox-dev/jetbrains-fish runs the same job with contents: write.
A tag run that accepts the Marketplace upload can still fail while publishing the GitHub release. Re-pushing the tag is not an option, and the release workflow only runs on tag push, so this dispatch publishes the release from the failed run's artifacts. It takes the tag as an input and runs from main, because a workflow dispatched on the tag would need the file to exist in the tag. Before publishing, the signed ZIP and notes are checked against the acceptance receipt the run uploaded, so the release cannot carry bytes other than those accepted by the Marketplace.
gaborbernat
added
bug
gaborbernat
added a commit
that referenced
this pull request
Nov 4, 2026
The v2.4.8 GitHub release is still missing. The recovery workflow from [#295](#295) fails before it publishes anything, because its job requires the `release` environment, and that environment only allows `v*` tags while the workflow runs from `main` (see [run 41798202652](https://github.com/tox-dev/PyVenvManage/actions/runs/41798202652)). 🚀 After this merges, a recovered release ends the way a normal tag run ends: the GitHub release is published, and then the version bump pull request is opened. The recovery workflow keeps its verification role. It takes the tag, the source run and the artifact IDs, checks the downloaded plugin ZIP and release notes against the Marketplace acceptance receipt, and only then publishes. Write access sits on that one job. The `release` environment is no longer part of the path, because the job reads no secrets and the receipt check is what guards the artifacts. The post-release jobs run after the publish job and use the same shared actions, with the same App token handling, as the tag workflow. They run in the `release-auth` environment, which already allows `main`, the branch this workflow is dispatched from. The tag workflow does not change.
gaborbernat
added a commit
that referenced
this pull request
Nov 4, 2026
The `finalize-github-release` workflow was added in [#295](#295) and [#296](#296) to finish releases whose GitHub release step hit a 403. That recovery path fails with the same 403, and the maintainer chose normal releases instead, so the workflow has no purpose left. Nothing else references it. Releases continue through the existing release workflow, which this change leaves untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The v2.4.8 tag run published the plugin to the JetBrains Marketplace, but the GitHub release was never created: the publish step failed with HTTP 403, and the post-release version bump was skipped. 🚀 This change lets the release job create the release, and adds a way to finish a release whose Marketplace upload was already accepted, without moving the tag.
The tag workflow keeps owning signing, the Marketplace check and the Marketplace publish. The GitHub release step gets write access on its job, matching the same job in tox-dev/jetbrains-fish, which publishes its releases the same way. A separate manual workflow takes the tag, the source run ID and the artifact IDs of that run. It checks the downloaded ZIP and release notes against the Marketplace acceptance receipt the run uploaded, then publishes the release. The manual workflow is dispatched from
main, because a dispatch on the tag would need the workflow file to exist in the tag, and the tag stays where it is.Impact
Future tag runs publish the GitHub release directly. Recovering a run like v2.4.8 becomes a single dispatch of the new workflow.
The recovery workflow does not open the post-release version bump PR. That PR still has to be created separately for v2.4.8.