Fix release tarballs OR attachment naming for better integration with build/dependency systems

[jfinkhaeuser]

Feature Description

When creating a release, gitea creates source tarballs. These have precisely the name of the tag, plus an extension. The root directory in the source tarball is the repository name.

The problem with this scheme is that it's not in line with the unspoken standards of distributing source code. Source tarballs are generally expected to

1. Contain a root directory following the pattern <projectname>-<release version>.
2. Be named according to the pattern <projectname>-<release version>.<extension>

Gitea does not produce tarballs according to this pattern. There are a few ways it could improve on this.

Alternatively, you can add custom attachments to a release, e.g. from a dist command from your build system. This may create tarballs in the expected format. Unfortunately, these attachments then have a URL that has nothing to do with the file name. Some dependency management systems (e.g. meson expect URLs to also contain the pattern <projectname>-<release version>, however.

Possible solutions include:

1. Make automatically generated tarballs contain the tag name as the root directory. This would permit generating the right tarballs by following a tagging scheme of <projectname>-<release version>.
2. Similar to the above, but default to naming the tarball and root directory <repo-name>-<tagname> - for projects following the common pattern of using release versions as tag names, this would probably be best.
3. Similar to the above, but make the naming patterns (separately?) configurable, e.g. from a small number of placeholders such as <repo-name>, etc. You can default to the current behaviour, but also use ones consistent with the expectations of other systems.
4. Somewhat orthogonal to this, allow for distinct naming of attachment URLs that includes the file name. All it would need is to add the file name at the end of the URL. You don't even need to handle that, you can keep the attachment ID as the main indentifier, and just accept anything in the URL path that follows.

Screenshots

No response

[noerw]

Sounds like good suggestions in general.
Changing the tarball directory layout, and possibly also the download filename is a breaking change that's near impossible to communicate to consumers of those tarballs in advance though. So I'm not sure this is worth breaking existing workflows.

[6543]

-> #9534

[eli-schwartz]

It's not clear to me how #9534 solves either one of the issues raised in this ticket? Why is this being closed?

[6543]

... Unfortunately, these attachments then have a URL that has nothing to do with the file name. ...

you still can use this it's just not shown on the frontend, because at the moment it's allowed to upload files with same name multible times as attachment ....

as soon as this is fixed ... we can switch back

[jfinkhaeuser]

Hmm, I'm a little unclear on how that'll work as well, but I'll wait and see.

[6543]

href="{{$.RepoLink}}/releases/download/{{$release.TagName | PathEscape}}/{{$attachment.Name | PathEscape}}"

would work ... but it's not shown as it could have name collisions ...

changing the name scheme for auto-generated source tarballs is also possible but would require work also