Repository navigation
Add support for draft Github releases #1193
Description
Feature Request
Description
GH supports draft releases (on the contrary to pre-releases) but I don't see any draft reference on GHA docs.
Currently I have the following GH workflow:
- name: Calculate version
uses: python-semantic-release/[email protected]
id: semantic-release
with:
root_options: "-c .semantic-release.toml"
github_token: ${{ steps.ghactions-auth.outputs.token }}
push: "false"
changelog: "false"
vcs_release: "false"
- name: Create GH release
uses: ncipollo/release-action@v1
with:
token: ${{ steps.ghactions-auth.outputs.token }}
tag: ${{ steps.semantic-release.outputs.tag }}
removeArtifacts: true
generateReleaseNotes: true
draft: true
allowUpdates: true
updateOnlyUnreleased: true
The above workflow runs only on feature (non-main) branches, determines the version and creates a draft GH release. If the release exists already, it is updated (i.e. the release notes are re-generated).
I'd like to move fully to python-semantic-release because it generates better decorated GH Release Notes.
Activity
github-actions commentedon Apr 20, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Apr 22, 2025
Still in backlog
github-actions commentedon Jun 23, 2025
It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
codejedi365 commentedon Jun 26, 2025
Still in backlog
github-actions commentedon Sep 26, 2025
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
rantoniuk commentedon Sep 26, 2025
@codejedi365 I guess you need to update the bot to exclude the issues with status
confirmedfrom the demotion process ;-)codejedi365 commentedon Sep 26, 2025
Actually, the stalebot is acting as intended. I implemented a different approach than most are accustomed to. The approach is that initially issues are created with
triageso that I can filter down to issues I have not yet looked at. After triage, I either respond with a question or answer and mark it withawaiting replyuntil it is clarified (this step is skipped if it is obvious and agreed upon). People have 14 days to respond or it is closed. Once the request or issue is clear, I place theconfirmedtag on the issue. This means it will never be closed arbitrarily by the bot and in order to keep the requester informed of progress (and that there is still a maintainer aware of your issue) the bot drops a message to ping us for an update on a timetable. So in this case it is not a demotion but a round robin approach to always come around to the issue again. Sometimes other problems take priority and this just ensures I am reviewing issues regularly and communicating to users.I still have a stale process but it's basically not used anymore since most issues land in these 2 buckets. It mainly applies to my own PRs if no update has occurred in 90 days.
github-actions commentedon Dec 26, 2025
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
feat: add draft release option
repairman29 commentedon Jan 9, 2026
Hi! I'm interested in contributing to this. Let me know if you'd like to discuss the implementation approach.
(Connected through Echeo)
github-actions commentedon Apr 9, 2026
It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
farhan commentedon Aug 27, 2026
Filed #1478 — GitHub's immutable releases freeze a release's assets at publish, so PSR's publish-then-upload flow now fails with
422 Cannot upload assets to an immutable release. Native draft-first support, as requested here, would let assets attach while the release is still a draft and fix that breakage.