=f.number_field:receive_max_input_size,class: 'form-control qa-receive-max-input-size-field',title: _('Maximum size limit for a single commit.'),data: {toggle: 'tooltip',container: 'body'}
[GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests), etc.
[GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests), etc.
...
@@ -227,6 +226,7 @@ requirements.
...
@@ -227,6 +226,7 @@ requirements.
1.[Changelog entry added](../changelog.md), if necessary.
1.[Changelog entry added](../changelog.md), if necessary.
1. Reviewed by relevant (UX/FE/BE/tech writing) reviewers and all concerns are addressed.
1. Reviewed by relevant (UX/FE/BE/tech writing) reviewers and all concerns are addressed.
1. Merged by a project maintainer.
1. Merged by a project maintainer.
1. Create an issue in the [infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues) to inform the Infrastructure department when your contribution is changing default settings or introduces a new setting, if relevant.
1. Confirmed to be working in the [Canary stage](https://about.gitlab.com/handbook/engineering/#canary-testing) or on GitLab.com once the contribution is deployed.
1. Confirmed to be working in the [Canary stage](https://about.gitlab.com/handbook/engineering/#canary-testing) or on GitLab.com once the contribution is deployed.
1. Added to the [release post](https://about.gitlab.com/handbook/marketing/blog/release-posts/),
1. Added to the [release post](https://about.gitlab.com/handbook/marketing/blog/release-posts/),
@@ -771,6 +771,9 @@ nicely on different mobile devices.
...
@@ -771,6 +771,9 @@ nicely on different mobile devices.
To make things easier for the user, always add a full code block for things that can be
To make things easier for the user, always add a full code block for things that can be
useful to copy and paste, as they can easily do it with the button on code blocks.
useful to copy and paste, as they can easily do it with the button on code blocks.
- Add a blank line above and below code blocks.
- Add a blank line above and below code blocks.
- When providing a shell command and its output, prefix the shell command with `$` and
leave a blank line between the command and the output.
- When providing a command without output, don't prefix the shell command with `$`.
- For regular code blocks, always use a highlighting class corresponding to the
- For regular code blocks, always use a highlighting class corresponding to the
language for better readability. Examples:
language for better readability. Examples:
...
@@ -795,7 +798,8 @@ nicely on different mobile devices.
...
@@ -795,7 +798,8 @@ nicely on different mobile devices.
- To display raw Markdown instead of rendered Markdown, you can use triple backticks
- To display raw Markdown instead of rendered Markdown, you can use triple backticks
with `md`, like the `Markdown code` example above, unless you want to include triple
with `md`, like the `Markdown code` example above, unless you want to include triple
backticks in the code block as well. In that case, use triple tildes (`~~~`) instead.
backticks in the code block as well. In that case, use triple tildes (`~~~`) instead.
-[Syntax highlighting for code blocks](https://github.com/rouge-ruby/rouge/wiki/List-of-supported-languages-and-lexers) is available for many languages.
-[Syntax highlighting for code blocks](https://github.com/rouge-ruby/rouge/wiki/List-of-supported-languages-and-lexers)
is available for many languages. Use `shell` instead of `bash` or `sh` for shell output.
- For a complete reference on code blocks, check the [Kramdown guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/#code-blocks).
- For a complete reference on code blocks, check the [Kramdown guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/#code-blocks).