[REPOS] releases download attachment limit 100 MB exceeded #129

sciss commented 2023年12月31日 01:15:24 +01:00

Hi. I'm having trouble attaching binary builds to my project: https://codeberg.org/sciss/Mellite-launcher/releases

The current interface rejects uploads greater than 100 MB. However, you can see that for the old tag 0.1.4 (which I want to delete once the uploads for 1.0.1 are complete) has actually a file greater than 100 MB, which seems was possible due to GitHub migration. Now the binaries are bundles with OpenJDK, and they easily exceed 100 MB depending on the compression and platform (.deb file being the biggest because worse compression than .zip).

Please increase the limit of releases attachment files to 200 MB.

Hi. I'm having trouble attaching binary builds to my project: https://codeberg.org/sciss/Mellite-launcher/releases The current interface rejects uploads greater than 100 MB. However, you can see that for the old tag 0.1.4 (which I want to delete once the uploads for 1.0.1 are complete) has actually a file greater than 100 MB, which seems was possible due to GitHub migration. Now the binaries are bundles with OpenJDK, and they easily exceed 100 MB depending on the compression and platform (.deb file being the biggest because worse compression than .zip). Please increase the limit of releases attachment files to 200 MB.

fnetX commented 2024年01月06日 15:13:16 +01:00

This touches upon technical limitations. The file size limit can only be configured globally. Increasing it will be considered, however it will affect all other users and potentially (inevitably) leads to more abuse.

I think we either need per-user-quotas or better moderation tooling. Ideally both.

This touches upon technical limitations. The file size limit can only be configured globally. Increasing it will be considered, however it will affect all other users and potentially (inevitably) leads to more abuse. I think we either need per-user-quotas or better moderation tooling. Ideally both.

pat-s commented 2024年06月04日 00:11:21 +02:00

@fnetX I also share the opinion on 100MB being already a large value for release assets. In the end, git hosters are no file hosters (even though the "packages" option is questioning this a bit) and one could argue that everything beyond is better stored in a dedicated remote file storage.

FWIW GitHub also has a 100MB limit and everything beyond goes into git-lfs. But this is again a different topic.

@sciss Is the request still of interest? I see the last commit was around the time of this request.

@fnetX I also share the opinion on 100MB being already a large value for release assets. In the end, git hosters are no file hosters (even though the "packages" option is questioning this a bit) and one could argue that everything beyond is better stored in a dedicated remote file storage. FWIW [GitHub also has a 100MB limit](https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github#file-size-limits) and everything beyond goes into `git-lfs`. But this is again a different topic. @sciss Is the request still of interest? I see the last commit was around the time of this request.

fnetX commented 2024年06月04日 00:20:08 +02:00

The request is for release attachments, not for storing data in Git itself.

Raising the limits kinda requires having proper quota to prevent abuse and people uploading their s* without thinking twice.

The request is for release attachments, not for storing data in Git itself. Raising the limits kinda requires having proper quota to prevent abuse and people uploading their s* without thinking twice.

pat-s commented 2024年06月04日 09:36:49 +02:00

The request is for release attachments, not for storing data in Git itself.

I understood that.

Still, such large release attachments (which sum up to 300MB+ for every release) are better hosted externally, no matter if running on CB or other git hosters?

I am aware that this request is not trying to abuse anything, and while it would be great to store such (large) release assets alongside the release directly, I'd personally argue that users should be encouraged to store such large assets externally (and outsource the (long term) storage burden).

> The request is for release attachments, not for storing data in Git itself. I understood that. Still, such large release attachments (which sum up to 300MB+ for every release) are better hosted externally, no matter if running on CB or other git hosters? I am aware that this request is not trying to abuse anything, and while it would be great to store such (large) release assets alongside the release directly, I'd personally argue that users should be encouraged to store such large assets externally (and outsource the (long term) storage burden).

gramps commented 2025年09月19日 18:08:53 +02:00

Sorry to revive this topic but our GodotSteam project has release files that creep over 100mb; the worst offender being the macOS ones or templates zips. While I'm not expecting Codeberg to raise this limit, is anyone aware of a good file storage solution that can be linked into the release section?

Sorry to revive this topic but our GodotSteam project has release files that creep over 100mb; the worst offender being the macOS ones or templates zips. While I'm not expecting Codeberg to raise this limit, is anyone aware of a good file storage solution that can be linked into the release section?

pat-s commented 2025年09月20日 08:48:14 +02:00

Use S3 and link to a dir which reflects the assets of your release tag

Use S3 and link to a dir which reflects the assets of your release tag

gramps commented 2025年09月21日 01:25:28 +02:00

Ah, I was hoping to avoid US-based hosting; especially things like Amazon. Thanks for the suggestion though, I will keep hunting!

Ah, I was hoping to avoid US-based hosting; especially things like Amazon. Thanks for the suggestion though, I will keep hunting!

fnetX commented 2025年09月21日 13:03:17 +02:00

@gramps Every file storage should work. Some people use Nextcloud or other providers, a static folder on their own server etc. Some people have put attachments into a Git repo with Git LFS.

I assume that we can raise the attachment size once we have enabled better storage quota.

@gramps Every file storage should work. Some people use Nextcloud or other providers, a static folder on their own server etc. Some people have put attachments into a Git repo with Git LFS. I assume that we can raise the attachment size once we have enabled better storage quota.

gramps commented 2025年09月22日 20:15:36 +02:00

Hmm, I read putting them into repos through LFS was bad practice. I'd also like to avoid tanking Codeberg's storage as much as possible. I'm sure I can figure something simple enough out. Thanks for the information! Once I can get these releases under 100 mb or Codeberg raises it a bit, I'll start hosting them here.

Hmm, I read putting them into repos through LFS was bad practice. I'd also like to avoid tanking Codeberg's storage as much as possible. I'm sure I can figure something simple enough out. Thanks for the information! Once I can get these releases under 100 mb or Codeberg raises it a bit, I'll start hosting them here.

pat-s commented 2025年09月22日 23:06:05 +02:00

Ah, I was hoping to avoid US-based hosting; especially things like Amazon.

There are many non-US S3 providers out there which are on top also much cheaper than AWS.

> Ah, I was hoping to avoid US-based hosting; especially things like Amazon. There are many non-US S3 providers out there which are on top also much cheaper than AWS.

gramps commented 2025年09月23日 00:25:29 +02:00

Oh really? I thought that term was specifically AWS; interesting.

Oh really? I thought that term was specifically AWS; interesting.

fnetX commented 2025年09月23日 00:28:11 +02:00

It is an AWS term. Some other competitors and libre tools have implemented the API, though. See https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services

It is an AWS term. Some other competitors and libre tools have implemented the API, though. See https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services

christiano commented 2025年09月23日 08:33:26 +02:00

Here you can find a list of European S3 alternatives: https://european-alternatives.eu/alternative-to/amazon-s3

Here you can find a list of European S3 alternatives: https://european-alternatives.eu/alternative-to/amazon-s3

gramps commented 2025年09月25日 22:23:17 +02:00

Thank you both for the links and information!

Thank you both for the links and information!