Increase attachment size on GitLab.com from 10MB to 100MB

Description of the problem

The gitlab.com site has a configured limit of 10MBs for file/attachment uploads. This prevents me from being able to upload pre-built packages (e.g. jar files, compressed asset archives, etc.) in a ready-to-use format for students that need to use the system. I wanted to add these resources for each release tag I add to the repository just like I was able to do here¹, but in other projects, such as this one².

This issue³ shows that GitHub was already offering 100MB of storage for such uploads; that was 2 years ago. (I'm using GitLab is because I think the MIT license for GitLab-CE is friendlier toward end-users.)

The request is to, hopefully, have the site's config value in the admin dashboard updated so that it accepts file attachments of larger sizes (e.g. at least 200MBs).

Which Group/Project (with full path) is experiencing the issue?

https://gitlab.com/ghost-in-the-zsh/rage

Approximate date/time when the error occurred.

I ran into the limitation on Saturday Nov. 4, but don't immediately remember the time of day.

Describe what you were doing right before the issue occurred.

Trying to upload a ~120MB file as an attachment for a release tag in this repository.

1. https://gitlab.com/ghost-in-the-zsh/rml/tags/v0.2.0-rc1

2. https://gitlab.com/ghost-in-the-zsh/rage

3. https://gitlab.com/gitlab-com/support-forum/issues/230

changed the description

@ghost-in-the-zsh Thanks for raising an issue. We have recently received another request for this.

@mydigitalself What do you think about increasing the attachment size limit? This is a global setting and it will affect all projects limits for attachments in release files, issues, mrs and comments.

It's something we will look at in the future, but not in the short-term.

Would it not be possible to store files such as this in the (or another) repository? Attachments are fairly unmanaged, whereas repository storage, or even LFS may be a better place to keep such artifacts.

I don't think we want to have to manage or even think about another repo for these files. We just want to attache "releases" of a size >10MB to a release (and/or tag). This would allow us to easily link customers/etc. to the specific location from which they need to download their latest release. I know we could also setup a "project-releases" repo and use that but it just seems very unnecessary and disconnected.

What's the downside to simply upping the configured maximum upload size? Sounds like it's a simple a config option.

@mydigitalself As @JoshMcCullough says, we're just looking to have the need of attaching the files that make up a proper tagged release to be addressed. Unfortunately, when someone says they intend to look at something "in the future, but not in the short-term", it's usually another way of saying "We won't look at this; ever" and I'm not sure if that's the case here :(

In any case, having another repository to simply upload binaries does not really make sense to me (e.g. from Git's usage point-of-view, etc.) and introduces unnecessary complications to the user-base.

It's fine that attachments are not managed; it doesn't look like there's any need for them to be managed (i.e. repository-backed) in the first place. They're just pre-built/binary packages that are supposed to make up a specific release, and we just need to attach them for easy downloading as part of those releases.

Currently, the file size limitation prevents the releases feature from being used to its full potential. The other alternatives I've come across, and/or have been suggested thus far, basically defeat the purpose of the feature and are also less straightforward/convenient for our audiences.

Based on images from the admin dashboard in the issue I linked to, the only change required is that of the file size limit value config option. No code changes would be required at all.

Considering that Gmail has a 25MB limit¹ for attachments, and that email is not a solution centered around software like GitLab is, I think having the config value updated to something more reasonable and in-line with the reality of software releases would be a well-received improvement :)

Thanks.

1. https://support.google.com/mail/answer/6584?co=GENIE.Platform%3DDesktop&hl=en

@ghost-in-the-zsh when I say "not managed" I mean the storage capability below it doesn't support object storage. We are in the process of moving all large files such as build artefacts & LFS storage to managed object storage and away from raw NFS storage, this way we can scale and manage our storage better.

Additionally, by "not managed" I mean the limit is primitive in that it's a per file limit. We want to extend attachments to be part of the 10G repository limit, which will include all code, registry & artefacts.

We have plans to move attachments to object storage, after this point we will look to increase that limit - but please note you will then have a 10G limit for all storage as part of our free plan, and will likely include additional storage in some of our paid plans.

Based on images from the admin dashboard in the issue I linked to, the only change required is that of the file size limit value config option. No code changes would be required at all.

We already have storage scaling challenges right now (including abuse), so a dramatic increase is not something that will be on the cards in the short-term until we have a managed storage solution for attachments.

@mydigitalself Thanks for your more detailed response. Is there, say, an idea of what "short-term" and "long-term" here means, i.e. a more concrete number/estimate? For example, if by "long-term" you mean in 2018, then that's one thing, but if that means, say, 2020, then that's very different. Also, what sort of priority does this kind of thing get from your team(s)?

I'm just trying to figure out if I can/should just wait it out here, or if I'll need to consider some other platform/setup that can actually fulfill my needs.

Thanks in advance.

@ghost-in-the-zsh always hard, we are undergoing a massive cloud platform migration at the moment which is taking priority ahead of this, so probably towards the end of 2018 I would think.

Let me move this issue into a better place and then we can keep an eye on timings.

removed milestone

@mydigitalself Any update on this issue? I am also trying to attach a medium size 26Mb file to a release and was surprised to see this limitation. Please advise. Bitbucket and Github have a place for these files. Gitlab should support this as well.

We have also recently run into this issue. We would also pay for it or upgrade the subscrption (within means)if required.

@mydigitalself Are there any updates on this, relative to your last comment? Also, why is this issue marked as closed?..

I'm trying to migrate away from GH. Not being able to attach release artifacts (fat jars can easily be 50MB or more) is a blocker, though. What's the recommended practice for binary release artifacts?

reopened

I'd like to see support for larger file uploads as well.

Anything new with this? I need to be able to upload binaries larger than 10MB as well. Even a 50MB limit would be more reasonable.

This would be useful in our day-day operations. Thanks for looking into it!

Ben

New to gitlab and lots to like but have immediately come up against a problem of trying to upload 40MB csv. Very grateful if limit could be increased even to 50MB

I am another user looking to migrate from Github, but this limitation would be a blocker for us. This has been an ongoing concern for more than a year now, with no indication of support from Gitlab.

Suggest a FREE tier upgrade to 100MB to address the immediate concerns, with the option of further upgrades for PAID tiers if need be.

@jeremy What do you think about this one please?

This is clearly being ignored by GitLab, and has been for over a year now. They've spent more time looking at this report, if at all, than what it would've probably taken to actually implement the requested change. I think it's embarrassing that email (yes, email) has better size limits for attachments than an actual software management platform has for software releases...

I decided to primarily self-host my repositories and use GitLab mainly as a dumb backup location...

Wow. Having purchased a business plan for my whole company and seeing this limitation is a huge turn-off. What's the problem GitLab?

@jramsay for your awareness.

It would be nice to at least be able to pay to increase this limit.

We're silver subscribers and are running into the same issue, 10MB is far too little for many of the attachments we need to include in issue reports. Please increase this limit.

One workaround for now is to use build artefacts instead, as these seem to have a significantly larger file limit.

It is a bit odd, I can easily upload a 6GB docker image, but can only attach or release 10MB packages...

We're using the free plan now, but would upgrade if the upgrade brought higher attachment limits.

changed title from Update GitLab.com config for attachment file size limit from 10MB to 200MB+ to Increase attachment size on GitLab.com; currently only 10MB

even though this is .com specific, I'm moving this to the CE tracker so that it can be properly triaged.

added GitLab.com Priority gitlab.com labels

added devopsgrowth label

added 1 deleted label

@timhey not sure if this would fall under your group? If not, any idea where?

@cynthia Not exactly sure where this one fits. I'll let you know if I find the right team for this one.

@timhey @cynthia - As discussed in Slack, I think this is an infrastructure decision (not product) as the capability to adjust this exists.

Agreed. Thanks for the guidance on this one @phikai

added featureenhancement infrastructure labels

added internal customer typefeature labels