Offer a download link to specific release file

[ahtcx]

How about one-upping GitHub and offering a direct download link to any file from any release. The best way I can think of would be with the following URL scheme, I don't they could interfere with any current ones.

URL	Download
/{user}/{repo}/releases/download/latest/{name}	name from latest stable release
/{user}/{repo}/releases/download/latest:stable/{name}	name from latest stable release
/{user}/{repo}/releases/download/latest:prerelease/{name}	name from latest prerelease
/{user}/{repo}/releases/download/tag:{tag}/{name}	name from specific release tag

The URLs should 302 to the attachement URL, if no file or release exists it should 404. If you like the idea but have bigger priorities I could look into implementing it myself, though it will take some time since I've never contributed to a big project, nor used Go.

This is really useful to provide a static URL to the latest release similar to wordpress.org/latest.zip that can be used by scripts. Instead it would look more like /wordpress/wordpress/releases/download/latest/wordpress.zip.

[ahtcx]

I'm not sure how it could be handled when a release offers multiple files with the same name, but who does that anyway?

[lafriks]

If semantic versioning of tags is taken into account I like the idea

[ahtcx]

/{user}/{repo}/releases/download/version:{constraint}/{name} would be pretty cool! I'm currently setting up the dev environment and hopefully I can implement this!

[ahtcx]

I'm currently working on this and am unsure how to "cleanly" tackle the problem of multiple attachements with the same name, do you think it would make sense to ban attachements with the same file name? If not any ideas of how to make every single attachement accessible, including files with the same name?

[lafriks]

I think that attachments with same name should not be allowed

[meoso]

I request this or similar also please. i was using https://dl.gitea.io/gitea/master/gitea-master-linux-amd64 up until very recently, now it no longer exists, so my weekly update script no longer works.

[lafriks]

@meoso it will be back soon again, we did move over infra to larger disk space, so not everything is back. As soon as our drone instance will be fully working again master downloads will be available again

[DjSni]

I think it should also be integrated into the API.
Is there any news ?

[l-2-j]

Handling multiple attachments with the exact same filename sounds like the 300 Multiple Choices status header would work well. At least if there's no other reason to deny multiple attachments with the same filename?

If I understand the specification of said header correctly, it could just return a list of attachments in a similar vein as the API already does for retrieving the attachments (/repos/{owner}/{repo}/releases/{id}/assets)? Though of course filtered to only contain the attachments with the matching filename.

_{And that way it could later on be potentially extended to match with just partial filenames (*.exe?partialmatch=true -> foo-vX.Y.Z.exe & bar-vZ.Y.X.exe) type of a thing.}

[Mai-Lapyst]

Is anyone currently working on this? If not I would start working on this.

[nerdCopter]

i would love URL = https://dl.gitea.io/gitea/master/gitea-master-linux-amd64 or similar. it worked great when it worked.

[Mai-Lapyst]

i would love URL = https://dl.gitea.io/gitea/master/gitea-master-linux-amd64 or similar. it worked great when it worked.

1. I think this is a bit off-topic from the original issue, but
2. This still works; the only thing is that the master branch was renamed to main: https://dl.gitea.io/gitea/main/gitea-main-linux-amd64

[Garionion]

I have had build a very simple api wrapper which (for now) does only a 307 (basically the same as 302) to the actual file.
gitea-attachements-proxy
there also exists a docker image
One can use the following patterns:

/:user/:repo/releases/download/latest/:name
/:user/:repo/releases/download/latest\\::channel/:name
/:user/:repo/releases/download/tag\\::tag/:name

eg: /garionion/fluffychat/releases/download/tag:v1.3.0/fluffychat-linux-x86.tar.zst

I wanted to do actual proxying and maybe caching but if gitea itself gets this feature i may abandon my "solution"

EDIT:
it uses GITEA_URL from env as upstream url

[Mai-Lapyst]

I did some work today on this and i fugured out that gitea currently provides an api for at least tag-based access to attachments; eg: /:user/:repo/releases/download/:tag/:fileName.

This now poses the problem that the new API cannot be implemented directly since it would require to remove the already existing API and thus making this feature a breaking change.

So the question is: do we want to switch to the new API / URL scheme or do we want an alternative route for this?