[Feature] store/link attachments externaly #4697

New Issue

GiteaMirror · 2025-11-02T05:59:52-06:00

GiteaMirror commented

2025-11-02 05:59:52 -06:00

Originally created by @scandinave on GitHub (Jan 21, 2020).

Gitea version (or commit ref): 1.12.0

Description

In my organisation we use a nexus repository to store the binary file produce from source code.
Creating a release's attachment by uploading this binary to gitea is redundant and double the disk usage.
It would be great to allow the use of an url instead of a file.

Originally created by @scandinave on GitHub (Jan 21, 2020).   - Gitea version (or commit ref): 1.12.0 ## Description In my organisation we use a nexus repository to store the binary file produce from source code. Creating a release's attachment by uploading this binary to gitea is redundant and double the disk usage. It would be great to allow the use of an url instead of a file.

GiteaMirror added the type/proposal label 2025-11-02 05:59:52 -06:00

GiteaMirror commented

2025-11-02 05:59:52 -06:00

@6543 commented on GitHub (Jan 21, 2020):

@scandinave i gues 1.13.6 is your Go version

for now you can insert links in the body
-> https://try.gitea.io/api/swagger#/repository/repoCreateRelease

@6543 commented on GitHub (Jan 21, 2020): @scandinave i gues `1.13.6` is your **Go** version for now you can insert links in the **body** -> https://try.gitea.io/api/swagger#/repository/repoCreateRelease

GiteaMirror commented

2025-11-02 05:59:52 -06:00

@6543 commented on GitHub (Jan 21, 2020):

do you mean [Feature] store/link attachments externaly ?

@6543 commented on GitHub (Jan 21, 2020): do you mean `[Feature] store/link attachments externaly` ?

GiteaMirror commented

2025-11-02 05:59:53 -06:00

@scandinave commented on GitHub (Jan 21, 2020):

@6543 oups yeah, the version is 1.12.0
Actually it's what we do in the body.
And yeah you can call it [Feature] store/link attachments externaly

I update my issue.

@scandinave commented on GitHub (Jan 21, 2020): @6543 oups yeah, the version is 1.12.0 Actually it's what we do in the body. And yeah you can call it `[Feature] store/link attachments externaly` I update my issue.

GiteaMirror commented

2025-11-02 05:59:53 -06:00

@zeripath commented on GitHub (Jan 21, 2020):

We should probably only create the release archive on first download. That will speed up our pushing of tags too.

@zeripath commented on GitHub (Jan 21, 2020): We should probably only create the release archive on first download. That will speed up our pushing of tags too.

GiteaMirror commented

2025-11-02 05:59:53 -06:00

@6543 commented on GitHub (Jan 21, 2020):

Or make it to a async task? (via go or add a Queue)?

@6543 commented on GitHub (Jan 21, 2020): Or make it to a async task? (via `go` or add a Queue)?

GiteaMirror commented

2025-11-02 05:59:53 -06:00

@guillep2k commented on GitHub (Jan 21, 2020):

We should probably only create the release archive on first download. That will speed up our pushing of tags too.

This would be really nice for repositories imported from CVS or similar; my repos have hundreds of tags that were never meant to be used as releases (more like checkpoints), or they were, but in most cases nobody cares about any release but the latest.

We could even delete old archives from time to time. 😁

@guillep2k commented on GitHub (Jan 21, 2020): > > > We should probably only create the release archive on first download. That will speed up our pushing of tags too. This would be _really nice_ for repositories imported from CVS or similar; my repos have hundreds of tags that were never meant to be used as releases (more like checkpoints), or they were, but in most cases nobody cares about any release but the latest. We could even delete old archives from time to time. 😁

GiteaMirror commented

2025-11-02 05:59:53 -06:00

@zeripath commented on GitHub (Jan 21, 2020):

@guillep2k that's exactly the use case I'm thinking of

@zeripath commented on GitHub (Jan 21, 2020): @guillep2k that's exactly the use case I'm thinking of

GiteaMirror commented

2025-11-02 05:59:54 -06:00

@lunny commented on GitHub (Jan 22, 2020):

#9567 will support to store binaries on s3-like storage, so that you could share them.

@lunny commented on GitHub (Jan 22, 2020): #9567 will support to store binaries on s3-like storage, so that you could share them.

GiteaMirror commented

2025-11-02 05:59:54 -06:00

@davidsvantesson commented on GitHub (Jan 22, 2020):

Is this same as #9107?

@davidsvantesson commented on GitHub (Jan 22, 2020): Is this same as #9107?

GiteaMirror commented

2025-11-02 05:59:54 -06:00

@6543 commented on GitHub (Jan 22, 2020):

kind of ... (from original issue perspective) #9107 is only for release ... gut i like the idear to add attachemnts via URL direcly to comments, issues, releases ... (most usecase is probably later via API)

@6543 commented on GitHub (Jan 22, 2020): kind of ... (from original issue perspective) #9107 is only for release ... gut i like the idear to add attachemnts via URL direcly to comments, issues, releases ... (most usecase is probably later via API)

GiteaMirror referenced this issue

2025-11-02 13:35:55 -06:00

[PR #4724] [MERGED] Git statistics in Activity tab #17477

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#4697