Commit 3fd2e47c authored by Craig Norris's avatar Craig Norris

Merge branch 'docs-aqualls-sourcecode1' into 'master'

Revisions to Create pages

See merge request gitlab-org/gitlab!52828
parents 8ea992e8 0fc21fff
...@@ -13,7 +13,8 @@ You can change the default maximum number of projects that users can create in t ...@@ -13,7 +13,8 @@ You can change the default maximum number of projects that users can create in t
Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**. Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
You can increase or decrease that `Default projects limit` value. You can increase or decrease that `Default projects limit` value.
- If you set `Default projects limit` to 0, users are not allowed to create projects in their users personal namespace. However, projects can still be created within a group. - If you set `Default projects limit` to 0, users are not allowed to create projects
in their users personal namespace. However, projects can still be created in a group.
## Max attachment size ## Max attachment size
...@@ -22,8 +23,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit ...@@ -22,8 +23,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`. From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`.
NOTE: NOTE:
If you choose a size larger than what is currently configured for the web server, If you choose a size larger than the configured value for the web server,
you will likely get errors. See the [troubleshooting section](#troubleshooting) for more you may receive errors. See the [troubleshooting section](#troubleshooting) for more
details. details.
## Max push size ## Max push size
...@@ -39,8 +40,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit ...@@ -39,8 +40,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
From here, you can increase or decrease by changing the value in `Maximum import size (MB)`. From here, you can increase or decrease by changing the value in `Maximum import size (MB)`.
NOTE: NOTE:
If you choose a size larger than what is currently configured for the web server, If you choose a size larger than the configured value for the web server,
you will likely get errors. See the [troubleshooting section](#troubleshooting) for more you may receive errors. See the [troubleshooting section](#troubleshooting) for more
details. details.
## Personal Access Token prefix ## Personal Access Token prefix
...@@ -64,12 +65,9 @@ using the `personal_access_token_prefix` field. ...@@ -64,12 +65,9 @@ using the `personal_access_token_prefix` field.
## Repository size limit **(STARTER ONLY)** ## Repository size limit **(STARTER ONLY)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#limit-project-size-ee). Repositories in your GitLab instance can grow quickly, especially if you are
Repositories within your GitLab instance can grow quickly, especially if you are
using LFS. Their size can grow exponentially, rapidly consuming available storage. using LFS. Their size can grow exponentially, rapidly consuming available storage.
To prevent this from happening, you can set a hard limit for your repositories' size.
To avoid this from happening, you can set a hard limit for your repositories' size.
This limit can be set globally, per group, or per project, with per project limits This limit can be set globally, per group, or per project, with per project limits
taking the highest priority. taking the highest priority.
...@@ -88,7 +86,7 @@ For instance, consider the following workflow: ...@@ -88,7 +86,7 @@ For instance, consider the following workflow:
Only a GitLab administrator can set those limits. Setting the limit to `0` means Only a GitLab administrator can set those limits. Setting the limit to `0` means
there are no restrictions. there are no restrictions.
These settings can be found within: These settings can be found in:
- Each project's settings: - Each project's settings:
1. From the Project's homepage, navigate to **Settings > General**. 1. From the Project's homepage, navigate to **Settings > General**.
...@@ -104,9 +102,9 @@ These settings can be found within: ...@@ -104,9 +102,9 @@ These settings can be found within:
1. Fill in the **Size limit per repository (MB)** field. 1. Fill in the **Size limit per repository (MB)** field.
1. Click **Save changes**. 1. Click **Save changes**.
The first push of a new project, including LFS objects, will be checked for size The first push of a new project, including LFS objects, is checked for size.
and **will** be rejected if the sum of their sizes exceeds the maximum allowed If the sum of their sizes exceeds the maximum allowed repository size, the push
repository size. is rejected.
NOTE: NOTE:
The repository size limit includes repository files and LFS, but does not include artifacts, uploads, The repository size limit includes repository files and LFS, but does not include artifacts, uploads,
...@@ -121,12 +119,12 @@ For GitLab.com repository size limits, see [accounts and limit settings](../../g ...@@ -121,12 +119,12 @@ For GitLab.com repository size limits, see [accounts and limit settings](../../g
### 413 Request Entity Too Large ### 413 Request Entity Too Large
If you are attaching a file to a comment or reply in GitLab and receive the `413 Request Entity Too Large` When attaching a file to a comment or reply in GitLab displays a `413 Request Entity Too Large`
error, it is likely caused by having a [max attachment size](#max-attachment-size) error, the [max attachment size](#max-attachment-size)
larger than what the web server is configured to allow. is probably larger than the web server's allowed value.
If you wanted to increase the max attachment size to 200m in a GitLab To increase the max attachment size to 200 MB in a
[Omnibus](https://docs.gitlab.com/omnibus/) install, for example, you might need to [Omnibus GitLab](https://docs.gitlab.com/omnibus/) install, you may need to
add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size: add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
```ruby ```ruby
...@@ -135,15 +133,15 @@ nginx['client_max_body_size'] = "200m" ...@@ -135,15 +133,15 @@ nginx['client_max_body_size'] = "200m"
## Limiting lifetime of personal access tokens **(ULTIMATE SELF)** ## Limiting lifetime of personal access tokens **(ULTIMATE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab Ultimate 12.6.
Users can optionally specify an expiration date for Users can optionally specify an expiration date for
[personal access tokens](../../profile/personal_access_tokens.md). [personal access tokens](../../profile/personal_access_tokens.md).
This expiration date is not a requirement, and can be set to any arbitrary date. This expiration date is not a requirement, and can be set to any arbitrary date.
Since personal access tokens are the only token needed for programmatic access to GitLab, Personal access tokens are the only tokens needed for programmatic access to GitLab.
organizations with security requirements may want to enforce more protection to require However, organizations with security requirements may want to enforce more protection by
regular rotation of these tokens. requiring the regular rotation of these tokens.
### Setting a limit ### Setting a limit
...@@ -164,10 +162,10 @@ Once a lifetime for personal access tokens is set, GitLab will: ...@@ -164,10 +162,10 @@ Once a lifetime for personal access tokens is set, GitLab will:
- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the - After three hours, revoke old tokens with no expiration date or with a lifetime longer than the
allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime, allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
or remove it, before revocation takes place. or remove it, before revocation takes place.
## Enforcement of SSH key expiration **(ULTIMATE ONLY)** ## Enforcement of SSH key expiration **(ULTIMATE ONLY)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in GitLab Ultimate 13.9.
> - It is deployed behind a feature flag, disabled by default. > - It is deployed behind a feature flag, disabled by default.
> - It is disabled on GitLab.com. > - It is disabled on GitLab.com.
> - It is not recommended for production use. > - It is not recommended for production use.
...@@ -201,13 +199,14 @@ Feature.disable(:ff_enforce_ssh_key_expiration) ...@@ -201,13 +199,14 @@ Feature.disable(:ff_enforce_ssh_key_expiration)
## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)** ## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1.
> - It is deployed behind a feature flag, disabled by default. > - It is deployed behind a feature flag, disabled by default.
> - It is disabled on GitLab.com. > - It is disabled on GitLab.com.
> - It is not recommended for production use. > - It is not recommended for production use.
> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature). **(FREE SELF)** > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature). **(FREE SELF)**
GitLab administrators can choose to prevent personal access tokens from expiring automatically. The tokens will be usable after the expiry date, unless they are revoked explicitly. GitLab administrators can choose to prevent personal access tokens from expiring
automatically. The tokens are usable after the expiry date, unless they are revoked explicitly.
To do this: To do this:
...@@ -244,4 +243,6 @@ To do this: ...@@ -244,4 +243,6 @@ To do this:
1. Check the **Prevent users from changing their profile name** checkbox. 1. Check the **Prevent users from changing their profile name** checkbox.
NOTE: NOTE:
When this ability is disabled, GitLab administrators will still be able to update the name of any user in their instance via the [Admin UI](../index.md#administering-users) or the [API](../../../api/users.md#user-modification) When this ability is disabled, GitLab administrators can still use the
[Admin UI](../index.md#administering-users) or the
[API](../../../api/users.md#user-modification) to update usernames.
...@@ -11,14 +11,14 @@ GitLab allows administrators to enforce specific controls. ...@@ -11,14 +11,14 @@ GitLab allows administrators to enforce specific controls.
To access the visibility and access control options: To access the visibility and access control options:
1. Log in to GitLab as an admin. 1. Sign in to GitLab as a user with Administrator [permissions](../../permissions.md).
1. Go to **Admin Area > Settings > General**. 1. Go to **Admin Area > Settings > General**.
1. Expand the **Visibility and access controls** section. 1. Expand the **Visibility and access controls** section.
## Default branch protection ## Default branch protection
This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_. branches. In this case _Default_ refers to a repository's default branch, which in most cases is `master`.
This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md). This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md).
...@@ -62,7 +62,7 @@ For more details, see [Default project-creation level](../../group/index.md#defa ...@@ -62,7 +62,7 @@ For more details, see [Default project-creation level](../../group/index.md#defa
By default, a project can be deleted by anyone with the **Owner** role, either at the project or By default, a project can be deleted by anyone with the **Owner** role, either at the project or
group level. group level.
To ensure only admin users can delete projects: To ensure only Administrator users can delete projects:
1. Check the **Default project deletion protection** checkbox. 1. Check the **Default project deletion protection** checkbox.
1. Click **Save changes**. 1. Click **Save changes**.
...@@ -71,16 +71,16 @@ To ensure only admin users can delete projects: ...@@ -71,16 +71,16 @@ To ensure only admin users can delete projects:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6.
By default, a project marked for deletion will be permanently removed with immediate effect. By default, a project marked for deletion is permanently removed with immediate effect.
By default, a group marked for deletion will be permanently removed after 7 days. By default, a group marked for deletion is permanently removed after seven days.
WARNING: WARNING:
The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to
[Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2. [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
Projects within a group (but not a personal namespace) can be deleted after a delayed period, by [configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal). Projects in a group (but not a personal namespace) can be deleted after a delayed period, by
[configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
The default period is 7 days, and can be changed. Setting this period to 0 will enable immediate removal The default period is seven days, and can be changed. Setting this period to `0` enables immediate removal
of projects or groups. of projects or groups.
To change this period: To change this period:
...@@ -149,13 +149,11 @@ For more details, see [Exporting a project and its data](../../../user/project/s ...@@ -149,13 +149,11 @@ For more details, see [Exporting a project and its data](../../../user/project/s
## Enabled Git access protocols ## Enabled Git access protocols
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4696) in GitLab 8.10.
With GitLab access restrictions, you can select with which protocols users can communicate with With GitLab access restrictions, you can select with which protocols users can communicate with
GitLab. GitLab.
Disabling an access protocol does not block access to the server itself via those ports. The ports Disabling an access protocol does not block access to the server itself by using those ports. The ports
used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the
application level. application level.
To specify the enabled Git access protocols: To specify the enabled Git access protocols:
...@@ -170,26 +168,26 @@ When both SSH and HTTP(S) are enabled, users can choose either protocol. ...@@ -170,26 +168,26 @@ When both SSH and HTTP(S) are enabled, users can choose either protocol.
When only one protocol is enabled: When only one protocol is enabled:
- The project page will only show the allowed protocol's URL, with no option to - The project page shows only the allowed protocol's URL, with no option to
change it. change it.
- A tooltip will be shown when you hover over the URL's protocol, if an action - A tooltip is shown when you hover over the URL's protocol, if an action
on the user's part is required, e.g. adding an SSH key, or setting a password. on the user's part is required. For example, adding an SSH key or setting a password.
![Project URL with SSH only access](img/restricted_url.png) ![Project URL with SSH only access](img/restricted_url.png)
On top of these UI restrictions, GitLab will deny all Git actions on the protocol On top of these UI restrictions, GitLab denies all Git actions on the protocol
not selected. not selected.
WARNING: WARNING:
Starting with [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021), GitLab versions [10.7 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021),
HTTP(S) protocol will be allowed for Git clone or fetch requests done by GitLab Runner allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner
from CI/CD jobs, even if _Only SSH_ was selected. from CI/CD jobs, even if **Only SSH** was selected.
## Custom Git clone URL for HTTP(S) ## Custom Git clone URL for HTTP(S)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18422) in GitLab 12.4. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18422) in GitLab 12.4.
You can customize project Git clone URLs for HTTP(S). This will affect the clone You can customize project Git clone URLs for HTTP(S), which affects the clone
panel: panel:
![Clone panel](img/clone_panel_v12_4.png) ![Clone panel](img/clone_panel_v12_4.png)
...@@ -225,10 +223,9 @@ For more details, see [SSH key restrictions](../../../security/ssh_keys_restrict ...@@ -225,10 +223,9 @@ For more details, see [SSH key restrictions](../../../security/ssh_keys_restrict
## Allow mirrors to be set up for projects ## Allow mirrors to be set up for projects
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3586) in GitLab 10.3. This option is enabled by default. By disabling it, both
[pull and push mirroring](../../project/repository/repository_mirroring.md) no longer
This option is enabled by default. By disabling it, both [pull and push mirroring](../../project/repository/repository_mirroring.md) will no longer work in every repository. They can only be re-enabled by an administrator user on a per-project basis.
work in every repository and can only be re-enabled by an admin on a per-project basis.
![Mirror settings](img/mirror_settings.png) ![Mirror settings](img/mirror_settings.png)
......
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment