Merge branch 'docs-repo-merge-19-user-admin-area' into 'master'

Docs: Merge EE doc/user/admin_area to CE

See merge request gitlab-org/gitlab-ce!27869

doc/user/admin_area/geo_nodes.md

+# Geo nodes admin area **[PREMIUM ONLY]**
+
+For more information about setting up GitLab Geo, read the
+[Geo documentation](https://docs.gitlab.com/ee/administration/geo/replication/index.html).
+
+When you're done, you can navigate to **Admin area > Geo** (`/admin/geo/nodes`).
+
+## Common settings
+
+All Geo nodes have the following settings:
+
+| Setting | Description |
+| --------| ----------- |
+| Primary | This marks a Geo Node as primary. There can be only one primary, make sure that you first add the primary node and then all the others. |
+| URL     | The instance's full URL, in the same way it is configured in  `/etc/gitlab/gitlab.rb` (Omnibus GitLab installations) or `gitlab.yml` (source based installations). |
+
+The node you're reading from is indicated with a green `Current node` label, and
+the primary is given a blue `Primary` label. Remember that you can only make
+changes on the primary!
+
+## Secondary node settings
+
+Secondaries have a number of additional settings available:
+
+| Setting                   | Description |
+|---------------------------|-------------|
+ Selective synchronization | Enable Geo [selective sync](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) for this **secondary** node. |
+| Repository sync capacity  | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling repositories. |
+| File sync capacity        | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling files. |
+
+## Geo backfill
+
+Secondaries are notified of changes to repositories and files by the primary,
+and will always attempt to synchronize those changes as quickly as possible.
+
+Backfill is the act of populating the secondary with repositories and files that
+existed *before* the secondary was added to the database. Since there may be
+extremely large numbers of repositories and files, it's infeasible to attempt to
+download them all at once, so GitLab places an upper limit on the concurrency of
+these operations.
+
+How long the backfill takes is a function of the maximum concurrency, but higher
+values place more strain on the primary node. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3107),
+the limits are configurable - if your primary node has lots of surplus capacity,
+you can increase the values to complete backfill in a shorter time. If it's
+under heavy load and backfill is reducing its availability for normal requests,
+you can decrease them.
+
+## Using a different URL for synchronization
+
+The **primary** node's Internal URL is used by **secondary** nodes to contact it
+(to sync repositories, for example). The name Internal URL distinguishes it from
+[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab)
+which is used by users. Internal URL does not need to be a private address.
+
+Internal URL defaults to External URL, but you can customize it under
+**Admin area > Geo Nodes**.

doc/user/admin_area/index.md

@@ -15,13 +15,16 @@ Only admin users can access the Admin Area.
 The Admin Area is made up of the following sections:
 
 | Section                    | Description                                                                                                                                              |
-|:------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
+|:---------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
 | Overview                   | View your GitLab [Dashboard](#admin-dashboard), and administer [projects](#administer-projects), users, groups, jobs, runners, and Gitaly servers.       |
 | Monitoring                 | View GitLab system information, and information on background jobs, logs, [health checks](monitoring/health_check.md), request profiles, and audit logs. |
 | Messages                   | Send and manage [broadcast messages](broadcast_messages.md) for your users.                                                                              |
 | System Hooks               | Configure [system hooks](../../system_hooks/system_hooks.md) for many events.                                                                            |
 | Applications               | Create system [OAuth applications](../../integration/oauth_provider.md) for integrations with other services.                                            |
 | Abuse Reports              | Manage [abuse reports](abuse_reports.md) submitted by your users.                                                                                        |
+| License **[STARTER ONLY]** | Upload, display, and remove [licenses](license.md).                                                                                                      |
+| Push Rules **[STARTER]**   | Configure pre-defined git [push rules](https://docs.gitlab.com/ee/push_rules/push_rules.html) for projects.                                              |
+| Geo **[PREMIUM ONLY]**     | Configure and maintain [Geo nodes](geo_nodes.md).                                                                                                        |
 | Deploy Keys                | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys).                                                                                 |
 | Service Templates          | Create [service templates](../project/integrations/services_templates.md) for projects.                                                                  |
 | Labels                     | Create and maintain [labels](labels.md) for your GitLab instance.                                                                                        |

doc/user/admin_area/license.md

+# Activate all GitLab Enterprise Edition functionality with a license **[STARTER ONLY]**
+
+To activate all GitLab Enterprise Edition (EE) functionality, you need to upload
+a license. Once you've received your license from GitLab Inc., you can upload it
+by **signing into your GitLab instance as an admin**.
+
+The license has the form of a base64 encoded ASCII text with a `.gitlab-license`
+extension and can be obtained when you [purchase one][pricing] or when you sign
+up for a [free trial].
+
+NOTE: **Note:**
+As of GitLab Enterprise Edition 9.4.0, a newly-installed instance without an
+uploaded license will only have the Core features active. A trial license will
+activate all Ultimate features, but after
+[the trial expires](#what-happens-when-your-license-expires), some functionality
+will be locked.
+
+## Uploading your license
+
+The very first time you visit your GitLab EE installation signed in as an admin,
+you should see a note urging you to upload a license with a link that takes you
+straight to the License admin area.
+
+Otherwise, you can:
+
+1. Navigate manually to the **Admin Area** by clicking the wrench icon in the menu bar.
+
+    ![Admin area icon](img/admin_wrench.png)
+
+1. And then going to the **License** tab and click on **Upload New License**.
+
+    ![License admin area](img/license_admin_area.png)
+
+1. If you've received a `.gitlab-license` file, you should have already downloaded
+   it in your local machine. You can then upload it directly by choosing the
+   license file and clicking the **Upload license** button. In the image below,
+   you can see that the selected license file is named `GitLab.gitlab-license`.
+
+    ![Upload license](img/license_upload.png)
+
+    If you've received your license as plain text, you need to select the
+    "Enter license key" option, copy the license, paste it into the "License key"
+    field and click **Upload license**.
+
+---
+
+Once the license is uploaded, all GitLab Enterprise Edition functionality
+will be active until the end of the license period. When that period ends, the
+instance will [fall back](#what-happens-when-your-license-expires) to Core-only
+functionality.
+
+You can review the license details at any time in the License section of the
+Admin Area.
+
+![License details](img/license_details.png)
+
+## Notification before the license expires
+
+One month before the license expires, a message informing when the expiration
+is due to, will start appearing to GitLab admins. Make sure that you update your
+license, otherwise you will miss all the paid features if it expires.
+
+## What happens when your license expires
+
+In case your license expires, GitLab will lock down some features like Git pushes,
+issue creation, etc., and a message to inform of the expired license will be
+presented to all admins.
+
+In order to get back all the previous functionality, a new license must be uploaded.
+To fall back to having only the Core features active, you'll need to delete the
+expired license(s).
+
+## License history
+
+It's possible to upload and view more than one license,
+but only the latest license will be used as the active license.
+
+[free trial]: https://about.gitlab.com/free-trial/
+[pricing]: https://about.gitlab.com/pricing/

doc/user/admin_area/settings/account_and_limit_settings.md

+# Account and limit settings
+
+## Repository size limit **[STARTER]**
+
+> [Introduced][ee-740] in [GitLab Enterprise Edition 8.12][ee-8.12].
+
+Repositories within your GitLab instance can grow quickly, especially if you are
+using LFS. Their size can grow exponentially and eat up your storage device quite
+fast.
+
+In order 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 taking the highest priority.
+
+There are numerous cases where you'll need to set up a limit for repository size.
+For instance, consider the following workflow:
+
+1. Your team develops apps which demand large files to be stored in
+   the application repository.
+1. Although you have enabled [Git LFS](../../../workflow/lfs/manage_large_binaries_with_git_lfs.html#git-lfs)
+   to your project, your storage has grown significantly.
+1. Before you blow your storage limit up, you set up a limit of 10 GB
+   per repository.
+
+### How it works
+
+Only a GitLab administrator can set those limits. Setting the limit to `0` means
+there are no restrictions.
+
+These settings can be found within:
+
+- Each project's settings.
+- A group's settings.
+- The **Size limit per repository (MB)** field in the **Account and limit** section of a GitLab instance's
+  settings by navigating to either:
+  - **Admin Area > Settings > General**.
+  - The path `/admin/application_settings`.
+
+The very first push of a new project cannot be checked for size as of now, so
+the first push will allow you to upload more than the limit dictates, but every
+subsequent push will be denied. LFS objects, however, can be checked on first
+push and **will** be rejected if the sum of their sizes exceeds the maximum
+allowed repository size.
+
+For more manually purging the files, read the docs on
+[reducing the repository size using Git][repo-size].
+
+> **Note:**
+> For GitLab.com, the repository size limit is 10 GB.
+
+[ee-740]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/740
+[repo-size]: ../../project/repository/reducing_the_repo_size_using_git.md
+[ee-8.12]: https://about.gitlab.com/2016/09/22/gitlab-8-12-released/#limit-project-size-ee

doc/user/admin_area/settings/continuous_integration.md

@@ -10,8 +10,8 @@ You can find it in the admin area, under **Settings > Continuous Integration and
 To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md)
 for all projects:
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
-1. Check (or uncheck to disable) the box that says "Default to Auto DevOps pipeline for all projects".
+1. Go to **Admin area > Settings > Continuous Integration and Deployment**
+1. Check (or uncheck to disable) the box that says "Default to Auto DevOps pipeline for all projects"
 1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/index.md#auto-devops-base-domain)
    which is going to be used for Auto Deploy and Auto Review Apps.
 1. Hit **Save changes** for the changes to take effect.
@@ -24,9 +24,9 @@ If you want to disable it for a specific project, you can do so in
 
 ## Maximum artifacts size **[CORE ONLY]**
 
-The maximum size of the [job artifacts][art-yml] can be set in the Admin area
-of your GitLab instance. The value is in *MB* and the default is 100MB per job;
-on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
+The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
+can be set in the Admin area of your GitLab instance. The value is in *MB* and
+the default is 100MB per job; on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
 
 To change it:
 
@@ -50,6 +50,79 @@ This setting is set per job and can be overridden in
 [`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in).
 To disable the expiration, set it to `0`. The default unit is in seconds.
 
+## Shared Runners pipeline minutes quota **[STARTER ONLY]**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1078)
+in GitLab Starter 8.16.
+
+If you have enabled shared Runners for your GitLab instance, you can limit their
+usage by setting a maximum number of pipeline minutes that a group can use on
+shared Runners per month. Setting this to `0` (default value) will grant
+unlimited pipeline minutes. While build limits are stored as minutes, the
+counting is done in seconds. Usage resets on the first day of each month.
+On GitLab.com, the quota is calculated based on your
+[subscription plan](https://about.gitlab.com/pricing/#gitlab-com).
+
+To change the pipelines minutes quota:
+
+1. Go to **Admin area > Settings > Continuous Integration and Deployment**
+1. Set the pipeline minutes quota limit.
+1. Hit **Save changes** for the changes to take effect
+
+---
+
+While the setting in the Admin area has a global effect, as an admin you can
+also change each group's pipeline minutes quota to override the global value.
+
+1. Navigate to the **Groups** admin area and hit the **Edit** button for the
+   group you wish to change the pipeline minutes quota.
+1. Set the pipeline minutes quota to the desired value
+1. Hit **Save changes** for the changes to take effect.
+
+Once saved, you can see the build quota in the group admin view.
+The quota can also be viewed in the project admin view if shared Runners
+are enabled.
+
+![Project admin info](img/admin_project_quota_view.png)
+
+When the pipeline minutes quota for a group is set to a value different than 0,
+the **Pipelines quota** page is available to the group page settings list.
+You can see there an overview of the pipeline minutes quota of all projects of
+the group.
+
+![Group pipelines quota](img/group_pipelines_quota.png)
+
+
+## Extra Shared Runners pipeline minutes quota
+
+NOTE: **Note:**
+Only available on GitLab.com.
+
+If you have a Group with a [paid plan](https://about.gitlab.com/pricing/#gitlab-com) on GitLab.com,
+then you can purchase additional CI minutes so your pipelines will not be blocked after you have
+used all your CI minutes from your main quota.
+
+In order to purchase additional minutes, you should follow these steps:
+
+1. Go to **Group > Settings > Pipelines quota**. Once you are on that page, click on **Buy additional minutes**.
+
+    ![Buy additional minutes](img/buy_btn.png)
+
+1. Locate the subscription card that is linked to your group on GitLab.com,
+click on **Buy more CI minutes**, and complete the details about the transaction.
+
+    ![Buy additional minutes](img/buy_minutes_card.png)
+
+1. Once we have processed your payment, the extra CI minutes
+will be synced to your Group and you can visualize it from  the
+**Group > Settings > Pipelines quota** page:
+
+    ![Additional minutes](img/additional_minutes.png)
+
+NOTE: **Important note**: If you have some minutes used over your default quota, these minutes will
+be deducted from your Additional Minutes quota immediately after your purchase of additional
+minutes.
+
 ## Archive jobs **[CORE ONLY]**
 
 Archiving jobs is useful for reducing the CI/CD footprint on the system by

doc/user/admin_area/settings/email.md

@@ -4,6 +4,22 @@
 
 The logo in the header of some emails can be customized, see the [logo customization section](../../../customization/branded_page_and_email_header.md).
 
+## Custom additional text **[PREMIUM ONLY]**
+
+>[Introduced][ee-5031] in [GitLab Premium][eep] 10.7.
+
+The additional text will appear at the bottom of any email and can be used for
+legal/auditing/compliance reasons.
+
+1. Go to **Admin area > Settings** (`/admin/application_settings`).
+1. Under the **Email** section, change the **Additional text** field.
+1. Hit **Save** for the changes to take effect.
+
+![Admin email settings](img/email_settings.png)
+
+[ee-5031]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5031
+[eep]: https://about.gitlab.com/pricing/
+
 ## Custom hostname for private commit emails
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22560) in GitLab 11.5.

doc/user/admin_area/settings/external_authorization.md

-# External authorization control
+# External authorization control **[CORE ONLY]**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4216) in
 > [GitLab Premium](https://about.gitlab.com/pricing) 10.6.

doc/user/admin_area/settings/index.md

@@ -6,6 +6,7 @@ instance like sign-up restrictions, account limits and quota, metrics, etc.
 Navigate to it by going to **Admin area > Settings**. Some of the settings
 include:
 
+- [Account and limit settings](account_and_limit_settings.md) **[STARTER]**
 - [Continuous Integration and Deployment](continuous_integration.md)
 - [Email](email.md)
 - [Sign up restrictions](sign_up_restrictions.md)
@@ -13,6 +14,7 @@ include:
 - [Third party offers](third_party_offers.md)
 - [Usage statistics](usage_statistics.md)
 - [Visibility and access controls](visibility_and_access_controls.md)
+- [Custom templates repository](instance_template_repository.md) **[PREMIUM]**
 
 NOTE: **Note:**
 You can change the [first day of the week](../../profile/preferences.md) for the entire GitLab instance

doc/user/admin_area/settings/instance_template_repository.md

+# Instance template repository **[PREMIUM ONLY]**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5986) in
+> [GitLab Premium](https://about.gitlab.com/pricing) 11.3.
+
+## Overview
+
+In hosted systems, enterprises often have a need to share their own templates
+across teams. This feature allows an administrator to pick a project to be the
+instance-wide collection of file templates. These templates are then exposed to
+all users [via the web editor](../../project/repository/web_editor.md#template-dropdowns)
+while the project remains secure.
+
+## Configuration
+
+As an administrator, navigate to **Admin area > Settings > Templates** and
+select the project to serve as the custom template repository.
+
+![File templates in the admin area](img/file_template_admin_area.png)
+
+Once a project has been selected, you can add custom templates to the repository,
+and they will appear in the appropriate places in the
+[frontend](../../project/repository/web_editor.md#template-dropdowns) and
+[API](../../../api/settings.md).
+
+Templates must be added to a specific subdirectory in the repository,
+corresponding to the kind of template. The following types of custom templates
+are supported:
+
+| Type              | Directory     | Extension     |
+| :---------------: | :-----------: | :-----------: |
+| `Dockerfile`      | `Dockerfile`  | `.dockerfile` |
+| `.gitignore`      | `gitignore`   | `.gitignore`  |
+| `.gitlab-ci.yml`  | `gitlab-ci`   | `.yml`        |
+| `LICENSE`         | `LICENSE`     | `.txt`        |
+
+Each template must go in its respective subdirectory, have the correct
+extension and not be empty. So, the hierarchy should look like this:
+
+```text
+|-- README.md
+|-- Dockerfile
+    |-- custom_dockerfile.dockerfile
+    |-- another_dockerfile.dockerfile
+|-- gitignore
+    |-- custom_gitignore.gitignore
+    |-- another_gitignore.gitignore
+|-- gitlab-ci
+    |-- custom_gitlab-ci.yml
+    |-- another_gitlab-ci.yml
+|-- LICENSE
+    |-- custom_license.txt
+    |-- another_license.txt
+```
+
+Once this is established, the list of custom templates will be included when
+creating a new file and the template type is selected. These will appear at the
+top of the list.
+
+![Custom template dropdown menu](img/file_template_user_dropdown.png)
+
+If this feature is disabled or no templates are present, there will be
+no "Custom" section in the selection dropdown.

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -49,5 +49,15 @@ block access to the server itself. The ports used for the protocol, be it SSH or
 HTTP, will still be accessible. What GitLab does is restrict access on the
 application level.
 
+## Allow mirrors to be set up for projects
+
+> [Introduced][ee-3586] in GitLab 10.3.
+
+This option is enabled by default. By disabling it, both pull and push mirroring will no longer
+work in every repository and can only be re-enabled on a per-project basis by an admin.
+
+![Mirror settings](img/mirror_settings.png)
+
 [ce-4696]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4696
 [ce-18021]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18021
+[ee-3586]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3586