Cannot draft release without tag #3705

New Issue

GiteaMirror · 2025-11-02T05:22:22-06:00

GiteaMirror commented

2025-11-02 05:22:22 -06:00

Originally created by @IzzySoft on GitHub (Jul 31, 2019).

Gitea version (or commit ref): 1.8.3, 1.9.0 (incl. Codeberg)
Git version: 2.11.0
Operating system: Linux Mint
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I usually draft my release notes while features get completed – so on the day of the release, I just need to tag and then publish the release. That works well here on Github – but doesn't seem to work with Gitea:

when trying to save a draft, Gitea forces me to specify a tag (which does not yet exist – and besides, I miss a drop-down with existing tags in that place)
when migrating a repo which on Github has such drafts (with no tags assigned), Gitea crashes with a 500 Server Error (reproducible, at Codeberg).

Suggested solution

Please permit saving Drafts without enforcing tags upon them. Helps for consistency – and also for "not forgetting things in the release notes".

PS: Just verified after updating my instance to 1.9.0 (issue still exists).

Originally created by @IzzySoft on GitHub (Jul 31, 2019). - Gitea version (or commit ref): 1.8.3, 1.9.0 (incl. Codeberg) - Git version: 2.11.0 - Operating system: Linux Mint - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description I usually draft my release notes while features get completed – so on the day of the release, I just need to tag and then publish the release. That works well here on Github – but doesn't seem to work with Gitea: * when trying to save a draft, Gitea forces me to specify a tag (which does not yet exist – and besides, I miss a drop-down with existing tags in that place) * when migrating a repo which on Github has such drafts (with no tags assigned), Gitea crashes with a 500 Server Error (reproducible, at Codeberg). ## Suggested solution Please permit saving Drafts without enforcing tags upon them. Helps for consistency – and also for "not forgetting things in the release notes". PS: Just verified after updating my instance to 1.9.0 (issue still exists).

GiteaMirror added the issue/confirmed type/bug labels 2025-11-02 05:22:22 -06:00

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@ashimokawa commented on GitHub (Aug 1, 2019):

Regarding

when migrating a repo which on Github has such drafts (with no tags assigned), Gitea crashes with a 500 Server Error

This should be considered a kind/bug

@ashimokawa commented on GitHub (Aug 1, 2019): Regarding > when migrating a repo which on Github has such drafts (with no tags assigned), Gitea crashes with a 500 Server Error This should be considered a kind/bug

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@IzzySoft commented on GitHub (Aug 1, 2019):

Indeed. And in a first step (regardless of whether "draft without tag" will be implemented) it should be caught and presented to the user. Currently, the 500 appears after the repo itself has been (successfully) imported – but before issues are imported. Thus

leaving the impression the entire process has failed (but a subsequent try will fail with "repo already exists")
not importing issues, wiki etc. (when selected), though that would be successful

So when encountering such a draft, only that draft should be skipped – until Gitea allows for such drafts to be created. And the user should be informed, like "Migration completed successfully, but N drafted releases have been skipped."

@IzzySoft commented on GitHub (Aug 1, 2019): Indeed. And in a first step (regardless of whether "draft without tag" will be implemented) it should be caught and presented to the user. Currently, the 500 appears *after* the repo itself has been (successfully) imported – but *before* issues are imported. Thus * leaving the impression the entire process has failed (but a subsequent try will fail with "repo already exists") * not importing issues, wiki etc. (when selected), though that would be successful So when encountering such a draft, ***only that draft*** should be skipped – until Gitea allows for such drafts to be created. And the user should be informed, like "Migration completed successfully, but N drafted releases have been skipped."

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@stale[bot] commented on GitHub (Sep 30, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Sep 30, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@IzzySoft commented on GitHub (Jan 16, 2020):

Just asking politely (no pressure, just informal): is this meanwhile on the agenda – and if so, is there a rough ETA for it? Waiting to move my last remaining projects to Codeberg 😉

@IzzySoft commented on GitHub (Jan 16, 2020): Just asking politely (no pressure, just informal): is this meanwhile on the agenda – and if so, is there a rough ETA for it? Waiting to move my last remaining projects to Codeberg 😉

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@lafriks commented on GitHub (Jan 16, 2020):

Currently noone is working on so no ETA can be given

@lafriks commented on GitHub (Jan 16, 2020): Currently noone is working on so no ETA can be given

GiteaMirror commented

2025-11-02 05:22:23 -06:00

@IzzySoft commented on GitHub (Jan 16, 2020):

Thanks, @lafriks – not was I hoped for, but there are so many tasks and only so much folks can do (as one of the F-Droid maintainers, I fully understand that situation)… Still, not giving up hope 😊

@IzzySoft commented on GitHub (Jan 16, 2020): Thanks, @lafriks – not was I hoped for, but there are so many tasks and only so much folks can do (as one of the F-Droid maintainers, I fully understand that situation)… Still, not giving up hope :blush:

GiteaMirror referenced this issue

2025-11-02 12:25:07 -06:00

[PR #3705] [MERGED] Multiple assignees #17050

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3705