feat: "draft" releases

crueter commented

2025-06-26 19:06:01 +00:00

Contributor

Having the action immediately create a release is really inconvenient, especially since in my case we have a somewhat different release workflow where I upload it externally rather than locally hosting it here.

earl-warren added the

question

label

2025-06-27 09:18:14 +00:00

earl-warren commented

2025-06-27 09:18:55 +00:00

Contributor

Could you please explain the use case in detail? Bullet points of chronologically ordered actions would be fine.

crueter commented

2025-06-27 09:34:20 +00:00

Author

Contributor

I push a tag to our repo, which builds the official release builds and creates an (ideally draft) release.
I download the release artifacts from the release.
Artifacts are uploaded to MEGA.
I remove the artifacts from our release, replacing them with direct-links to MEGA.

In the future, I plan to move my release workflow to GitHub Actions, but that itself is risky for us; having Forgejo be a direct option for handling our release workflow is always helpful here.

Also worth mentioning that in the short time between me downloading and deleting the artifacts, our server gets FLOODED with traffic as everyone flocks to download it. Having an option to make it a draft release also solves this issue since I'm the only one who can access it.

- I push a tag to our repo, which builds the official release builds and creates an (ideally draft) release. - I download the release artifacts from the release. - Artifacts are uploaded to MEGA. - I remove the artifacts from our release, replacing them with direct-links to MEGA. In the future, I plan to move my release workflow to GitHub Actions, but that itself is risky for us; having Forgejo be a direct option for handling our release workflow is always helpful here. Also worth mentioning that in the short time between me downloading and deleting the artifacts, our server gets FLOODED with traffic as everyone flocks to download it. Having an option to make it a draft release also solves this issue since I'm the only one who can access it.

👍 1

earl-warren commented

2025-06-27 10:05:29 +00:00

Contributor

It is crystal clear.

FWIW, here is how the Forgejo project itself organizes release management. The key is to have dedicated integration and exprimental organizations.

It roughly goes like this:

Push a tag to the integration repository which publishes all artifacts in the integration organization (binaries but also container images)
The workflow then copies all artifacts to the experimental repository and organization, from which test instances are spawned and people play with it before actually publishing the release
Last step is to copy to the forgejo organization which, in your case, would mean having links to MEGA (which I don't know about but assume to be a place where people can download the assets that you built)

It is crystal clear. FWIW, here is how the Forgejo project itself organizes release management. The key is to have dedicated integration and exprimental organizations. - https://forgejo.org/docs/next/contributor/release/#integration-and-experimental-organization - https://forgejo.org/docs/next/contributor/release/#automated-experimental-releases It roughly goes like this: - Push a tag to the integration repository which publishes all artifacts in the integration organization (binaries but also container images) - The workflow then copies all artifacts to the experimental repository and organization, from which test instances are spawned and people play with it before actually publishing the release - Last step is to copy to the forgejo organization which, in your case, would mean having links to MEGA (which I don't know about but assume to be a place where people can download the assets that you built)

crueter commented

2025-07-20 20:43:55 +00:00

Author

Contributor

I recently "solved" this by moving everything to GitHub actions triggered by webhooks (and now I don't have to murder my poor CI computers lol).

Though this is not a permanent solution since my CI repo on GitHub is in fact in danger due to the nature of our project.

I recently "solved" this by moving everything to GitHub actions triggered by webhooks (and now I don't have to murder my poor CI computers lol). Though this is not a permanent solution since my CI repo on GitHub is in fact in danger due to the nature of our project.

bacon commented

2025-09-02 23:50:36 +00:00

Bump, I have a much different use case but a draft release would be really good.

Current workflow is:

Tag is pushed to repo
Repo triggers release CI that builds the application and uploads the artifact
Artifact is uploaded to a draft release along with a template for release notes to be then edited and published as the actual release.

Bump, I have a much different use case but a draft release would be really good. Current workflow is: - Tag is pushed to repo - Repo triggers release CI that builds the application and uploads the artifact - Artifact is uploaded to a draft release along with a template for release notes to be then edited and published as the actual release.

earl-warren commented

2025-09-03 05:46:00 +00:00

Contributor

Do you have a publicly available URL where this workflow can be seen?

earl-warren commented

2025-09-03 05:50:56 +00:00

Contributor

It seems that it is different from what @crueter originally asked, which was to have private releases (not visible). This is a feature Forgejo does not currently have. I described how the Forgejo project manages the preparation of releases, which is in part by using private repositories or organizations. This not only addresses the need described by this question but also the need of releases that involve packages in addition to release artifacts managed by this action.

I am going to close this question as being answered. If you think it is worth pursuing the idea of having private releases, please open a feature request at Forgejo.

It seems that it is different from what @crueter originally asked, which was to have private releases (not visible). This is a feature Forgejo does not currently have. I described how the Forgejo project manages the preparation of releases, which is in part by using private repositories or organizations. This not only addresses the need described by this question but also the need of releases that involve packages in addition to release artifacts managed by this action. I am going to close this question as being answered. If you think it is worth pursuing the idea of having private releases, please open a [feature request at Forgejo](https://codeberg.org/forgejo/forgejo/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml).

earl-warren closed this issue

2025-09-03 05:50:56 +00:00

earl-warren commented

2025-09-03 05:52:04 +00:00

Contributor

@bacon if you have a different use case, could you please open a new issue? It is best to not confuse this use case with yours so they can be discussed separately 🙏

crueter commented

2025-09-03 11:56:18 +00:00

Author

Contributor

For further clarity, I have a similar use case of draft releases, not necessarily "private" ones.

For further clarity, I have a similar use case of draft releases, not *necessarily* "private" ones.

earl-warren reopened this issue

2025-09-03 17:03:50 +00:00

crueter changed title from ~~feat: allow for private/draft releases~~ to feat: "draft" releases

2025-09-03 17:12:08 +00:00

crueter referenced this issue from a pull request that will close it,

2025-11-12 02:20:06 +00:00

feat: allow for draft releases #99

randysimons commented

2025-12-23 22:16:53 +00:00

I as well have similar use case. Using the action to prepare a release, but before publishing, I check things, and manually add a description and release notes.

Also for consideration:

Marking a release as "draft" is part of the API, so why not expose it in the action?
3 of the 4 alternatives listed at GitHub support the draft option.

As temporary work-around, I use @crueter 's branch in my yaml, and (for my case) it works fine: uses: https://code.forgejo.org/crueter/forgejo-release@draft

I as well have similar use case. Using the action to prepare a release, but before publishing, I check things, and manually add a description and release notes. Also for consideration: - Marking a release as "draft" is part of the API, so why not expose it in the action? - 3 of the 4 alternatives [listed at GitHub](https://github.com/actions/create-release) support the `draft` option. As temporary work-around, I use @crueter 's branch in my yaml, and (for my case) it works fine: `uses: https://code.forgejo.org/crueter/forgejo-release@draft`

Rows
Columns

feat: "draft" releases #56