Enforce maximum attachment size in project API uploads by default
This makes the feature flag enforce_max_attachment_size_upload_api
enabled by default. Previously all uploads via the project API could
bypass the maximum attachment size limit. Now, Workhorse will cut off
the transfer with a "413 Request entity too large" message when that
limit is hit.
This has been enabled on GitLab.com with an exception list since GitLab 13.11.
Relates to #325787 (closed)
Merge request reports
Activity
assigned to @stanhu
changed milestone to %14.0
added api grouprelease [DEPRECATED] labels
- A deleted user
added backend documentation labels
2 Warnings Please add a merge request type to this merge request. You've made some app changes, but didn't add any tests.
That's OK as long as you're refactoring existing code,
but please consider adding any of the tooling, ~"tooling::pipelines", ~"tooling::workflow", documentation, QA labels.1 Message This merge request adds or changes documentation files. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge. Documentation review
The following files require a review from a technical writer:
doc/api/projects.md
The review does not need to block merging this merge request. See the:
-
Metadata for the
*.md
files that you've changed. The first few lines of each*.md
file identify the stage and group most closely associated with your docs change. - The Technical Writer assigned for that stage and group.
- Documentation workflows for information on when to assign a merge request for review.
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
Category Reviewer Maintainer backend Sean Arnold ( @seanarnold
) (UTC+12, 19 hours ahead of@stanhu
)Thong Kuah ( @tkuah
) (UTC+12, 19 hours ahead of@stanhu
)If needed, you can retry the
danger-review
job that generated this comment.Generated by
Danger- Resolved by Suzanne Selhorn
added twtriaged label
added feature flag label and removed backend documentation twtriaged labels
added twtriaged label
requested review from @axil and @seanarnold
requested review from @tkuah and removed review request for @seanarnold
Setting label(s) ~"devops::release" sectionops based on ~"group::release".
added devopsrelease [DEPRECATED] sectionops labels
removed review request for @tkuah
requested review from @kpaizee
added Technical Writing docsfeature documentation twdoing labels and removed twtriaged label
mentioned in issue gitlab-com/www-gitlab-com#11835 (closed)
- Resolved by Stan Hu
@kpaizee I've pushed !63459 (merged) to make the info a bit clearer on the Project API page. You'll probably want to compare and rebase depending on which MR gets merged first.
mentioned in merge request !63459 (merged)
mentioned in commit e9ba9fad
added workflowstaging label
added workflowcanary label and removed workflowstaging label
added workflowproduction label and removed workflowcanary label
added releasedcandidate label
mentioned in issue gitlab-com/www-gitlab-com#11986 (closed)
mentioned in merge request kubitus-project/kubitus-installer!39 (merged)
added releasedpublished label and removed releasedcandidate label
added typemaintenance label
mentioned in merge request !112450 (merged)