github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Offer a download link to specific release file #1647

New Issue
Open
opened 2025-11-02 04:08:20 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 04:08:20 -06:00
Owner
Copy Link

Originally created by @ahtcx on GitHub (Mar 23, 2018).

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.

Originally created by @ahtcx on GitHub (Mar 23, 2018). 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`.
GiteaMirror added the type/proposal label 2025-11-02 04:08:20 -06:00
GiteaMirror commented 2025-11-02 04:08:20 -06:00
Author
Owner
Copy Link

@ahtcx commented on GitHub (Mar 23, 2018):

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

@ahtcx commented on GitHub (Mar 23, 2018): I'm not sure how it could be handled when a release offers multiple files with the same name, but who does that anyway?
GiteaMirror commented 2025-11-02 04:08:21 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Mar 23, 2018):

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

@lafriks commented on GitHub (Mar 23, 2018): If semantic versioning of tags is taken into account I like the idea
GiteaMirror commented 2025-11-02 04:08:21 -06:00
Author
Owner
Copy Link

@ahtcx commented on GitHub (Mar 24, 2018):

/{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 commented on GitHub (Mar 24, 2018): `/{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!
GiteaMirror commented 2025-11-02 04:08:21 -06:00
Author
Owner
Copy Link

@ahtcx commented on GitHub (Mar 25, 2018):

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?

@ahtcx commented on GitHub (Mar 25, 2018): 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?
GiteaMirror commented 2025-11-02 04:08:22 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Mar 25, 2018):

I think that attachments with same name should not be allowed

@lafriks commented on GitHub (Mar 25, 2018): I think that attachments with same name should not be allowed
GiteaMirror commented 2025-11-02 04:08:22 -06:00
Author
Owner
Copy Link

@njdro commented on GitHub (Apr 3, 2018):

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.

@njdro commented on GitHub (Apr 3, 2018): 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.
GiteaMirror commented 2025-11-02 04:08:22 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Apr 3, 2018):

@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

@lafriks commented on GitHub (Apr 3, 2018): @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
GiteaMirror commented 2025-11-02 04:08:22 -06:00
Author
Owner
Copy Link

@DjSni commented on GitHub (Aug 18, 2019):

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

@DjSni commented on GitHub (Aug 18, 2019): I think it should also be integrated into the API. Is there any news ?
GiteaMirror commented 2025-11-02 04:08:22 -06:00
Author
Owner
Copy Link

@l-2-j commented on GitHub (May 4, 2022):

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.

@l-2-j commented on GitHub (May 4, 2022): Handling multiple attachments with the exact same filename sounds like the [`300 Multiple Choices`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300) 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](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.1) 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. <sub>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.</sub>
GiteaMirror commented 2025-11-02 04:08:23 -06:00
Author
Owner
Copy Link

@Mai-Lapyst commented on GitHub (May 29, 2022):

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

@Mai-Lapyst commented on GitHub (May 29, 2022): Is anyone currently working on this? If not I would start working on this.
GiteaMirror commented 2025-11-02 04:08:23 -06:00
Author
Owner
Copy Link

@nerdCopter commented on GitHub (May 29, 2022):

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

@nerdCopter commented on GitHub (May 29, 2022): i would love URL = `https://dl.gitea.io/gitea/master/gitea-master-linux-amd64` or similar. it worked great when it worked.
GiteaMirror commented 2025-11-02 04:08:23 -06:00
Author
Owner
Copy Link

@Mai-Lapyst commented on GitHub (May 29, 2022):

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
@Mai-Lapyst commented on GitHub (May 29, 2022): > 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
GiteaMirror commented 2025-11-02 04:08:23 -06:00
Author
Owner
Copy Link

@Garionion commented on GitHub (May 31, 2022):

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

@Garionion commented on GitHub (May 31, 2022): 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](https://git.entr0py.de/garionion/gitea-attachements-proxy) there also exists a [docker image](https://hub.docker.com/repository/docker/garionion/gitea-attachements-proxy) 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
GiteaMirror commented 2025-11-02 04:08:24 -06:00
Author
Owner
Copy Link

@Mai-Lapyst commented on GitHub (May 31, 2022):

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?

@Mai-Lapyst commented on GitHub (May 31, 2022): 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?
GiteaMirror commented 2025-11-02 04:08:24 -06:00
Author
Owner
Copy Link

@dboreham commented on GitHub (Apr 10, 2023):

Is anyone working on this? It looks pretty straightforward to implement. Add another route like this one : https://github.com/go-gitea/gitea/blob/main/routers/web/web.go#L961 to signify "latest" (we can't just specify a vTag of "latest" because that might be a valid tag) and extend the code here to pick the latest release: https://github.com/go-gitea/gitea/blob/main/routers/web/repo/repo.go#L359

@dboreham commented on GitHub (Apr 10, 2023): Is anyone working on this? It looks pretty straightforward to implement. Add another route like this one : https://github.com/go-gitea/gitea/blob/main/routers/web/web.go#L961 to signify "latest" (we can't just specify a `vTag` of "latest" because that might be a valid tag) and extend the code here to pick the latest release: https://github.com/go-gitea/gitea/blob/main/routers/web/repo/repo.go#L359
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1647
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?