Increment max size of artifacts for child/dynamic pipelines

I just ran into this limit, which doesn't appear to be documented and based on https://docs.gitlab.com/ee/user/gitlab_com/index.html#gitlab-cicd you'd think it was 1GB on GitLab.com

I have a GitLab Premium self-managed customer who is interested in this feature.

Link to request: SFDC Link Internal
Priority: customer priority7
Why interested: This change would allow there to be a more lax limit, and thus more flexibility when writing our pipelines & jobs.
Current solution for this problem: None. Limit is hit and they have to make changes.
Impact to the customer of not having this:
Questions: Is there any update on when the fix would be coming for this issue.
PM to mention: @jreporter

cc: @jrector @htehara

thanks @shoyle1!

@joshlambert - in relation to our consumption effort is there any reason why we wouldn't implement this from a business POV (I would expect to add this limit support only in self-managed)

@jreporter - I would imagine we would still want some limit on GitLab.com, otherwise it may be a vector for abuse or some other kind of attack.

The other aspect to think about would be how easy it is to manage these resulting pipeline artifacts. Are they still subject to expiration policies? If you have an overly generous policy, and want to clean some up, how easy is that?

@joshlambert the proposal is to let people set a limit higher than today. I would not want us to set an exorbitantly high limit for artifacts on GitLab.com

We already have a workstream in Category:Build Artifacts dedicated to making artifacts easier to manage. I just wanted to confirm there weren't other changes related your project that implementing this higher limit for self-manage would conflict.

Also, to be clear there is already a GitLab.com limit of 1GB (https://docs.gitlab.com/ee/user/gitlab_com/#gitlab-cicd)

@jreporter @jocelynjane the limit of 1 GB on Gitlab.com is for artifacts upload. The hard-coded limit of 5 MB is for dynamically generate CI configs that are being read in memory on the server side. We set that limit as MVC which allows us to be comfortable with reading 5 MB of files in order to merge CI configurations in memory: !88104 (comment 956698170)

We could definitely allow admins to change this limit as long as we also make them aware of the risks.

/cc @marcel.amirault

That makes a lot of sense thanks @fabiopitino for confirming. @jocelynjane - definitely worth prioritizing in the near future. I did have a recent call that discussed these limits as being non-starters.

There is a GitLab Premium self-managed customer who is also interested in having that limit be configurable as the current behavior requires them to manually adjust that limit in the source for their CI/CD pipelines to work properly. GitLab team members with access to Zendesk can learn more in the ticket.

I'm posting this in case it can help anyone else. My company has experienced this exact issue. We are using self-managed Docker deployments of GitLab.

As a work-around until this is fixed in an official release, we've just added the following line to our Dockerfile:

"RUN sed -i 's/MAX_ARCHIVE_SIZE = 5.megabytes/MAX_ARCHIVE_SIZE = 50.megabytes/' /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/ci/artifact_file_reader.rb"

Then, we rebuild the GitLab Docker image and re-deploy our instance. Since it's Docker, it's a very quick fix for us.

added to epic &4019

Customer interested in this: https://gitlab.my.salesforce.com/00161000002xBcU

as this is an advanced CI/CD option, adding this to GitLab Premium

added GitLab Premium label

A Premium self-managed k8s customer has run up against this issue, and modifying the source code is not a great option for them (ZD internal link)

mentioned in merge request !88104 (merged)

removed customer label

changed milestone to %15.2

added needs weight label

@shampton this one needs weight - I'd like to see if we can get this in between %15.2 and %15.4. Thoughts? Thanks!

@jocelynjane we're at capacity for %15.2. WDYT about moving this to %15.3 instead?

@jocelynjane @shampton

Do we want to introduce this limit at the instance or project or namespace level?

@morefice We should introduce this at the instance level so that self-managed admins can choose what their limit is.

This issue was initially for SaaS which means the customer would like us to increase the limit of our SaaS instance, but we'll need to ensure that it is safe before we do so. I think a good iteration is to make this more easily configurable by admins instead of hardcoded, and then we can determine if we should increase that limit for SaaS.

/cc @jocelynjane

Agree with @shampton. Is the proposal to keep the existing size as default and allow for the changes? @gdoyle adding you for awareness and potential Design input (longer term, does it make sense to have this as part of an admin panel?).

@shampton @jocelynjane

We should introduce this at the instance level so that self-managed admins can choose what their limit is.

Agreed to introduce this feature at the instance level as well.

Is the proposal to keep the existing size as default and allow for the changes?

I would suggest to set the default size with the existing limit we have today.

adding you for awareness and potential Design input (longer term, does it make sense to have this as part of an admin panel?).

If we add this setting at the instance level, I think we don't need a design for this first iteration as users administrator will customize the limit as follow:

ApplicationSetting.update(max_archive_size: 5.megabytes)

Questions

Do we know on which page this should live if we decide later on to make this configurable on the UI?
Looks like this issue is marked at GitLab Premium, any particular reason we choose to make this a GitLab Premium feature?

Just updated the proposal with what we discussed so far.

@morefice Just so I understand, will this only be available in the API at first for instances? Also, can we bake in some instrumentation for this since it's a new feature? Specifically the count of users who customize the setting so we can ensure that it is being used. Depending on usage metrics, we could always spend time adding this into the UI and iterating on it to support more! @jocelynjane @shampton

+1 on instrumentation! Good call out @gdoyle.

Looks like this issue is marked at GitLab Premium, any particular reason we choose to make this a GitLab Premium feature?

This is considered an advanced CI/CD feature (reference comment).

@gdoyle

Just so I understand, will this only be available in the API at first for instances?

From my understanding, this will only be available at for administrator as a custom setting but not exposed to the API.

Also, can we bake in some instrumentation for this since it's a new feature?

Great idea, agreed this sounds important to me as well, adding it to the proposal

@jocelynjane

This is considered an advanced CI/CD feature

Agreed, I'm trying to understand how we could implement this for SAAS vs self-managed as @alberts-gitlab mentionned

@morefice thanks for the clarification! I'm okay moving forward and seeing how the instrumentation plays out so we could then iterate on the feature further.

changed milestone to %15.3

A large premium customer is also seeing this issue and would like to be able to configure this limit on their self-managed instance

added VerifyP2 label

changed the description

assigned to @morefice

Thanks for working on this @morefice! We've removed the Seeking community contributions label to avoid having multiple people working on the same issue.

removed [deprecated] Accepting merge requests label

Increment max size of artifacts for child/dynamic pipelines

Proposal

Designs

Child items ...

Activity

Questions

Increment max size of artifacts for child/dynamic pipelines

Proposal

Relates to

Activity

Questions