Add latest changes from gitlab-org/gitlab@master

8 files changed, 122 insertions, 24 deletions

diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
index a919dd769f7..35c41dbd7ef 100644
--- a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
+++ b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
@@ -46,7 +46,7 @@ The project will be automatically configured to connect to the
 instance is present (should be the case if GitLab was installed via Omnibus
 and you haven't disabled it).
 
-If that's not the case or if you have an external Prometheus instance or an HA setup,
+If that's not the case or if you have an external Prometheus instance or a customized setup,
 you should
 [configure it manually](../../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index d39a7bdecfa..26244368234 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -57,9 +57,9 @@ The following reference architectures are available:
 - [Up to 25,000 users](25k_users.md)
 - [Up to 50,000 users](50k_users.md)
 
-## Availability components
+## Availability Components
 
-GitLab comes with the following availability components for your use, listed from
+GitLab comes with the following components for your use, listed from
 least to most complex:
 
 1. [Automated backups](#automated-backups-core-only)
@@ -68,11 +68,11 @@ least to most complex:
 1. [Automated database failover](#automated-database-failover-premium-only)
 1. [Instance level replication with GitLab Geo](#instance-level-replication-with-gitlab-geo-premium-only)
 
-As you get started implementing HA, begin with a single server and then do
+As you implement these components, begin with a single server and then do
 backups. Only after completing the first server should you proceed to the next.
 
-Also, not implementing HA for GitLab doesn't necessarily mean that you'll have
-more downtime. Depending on your needs and experience level, non-HA servers can
+Also, not implementing extra servers for GitLab doesn't necessarily mean that you'll have
+more downtime. Depending on your needs and experience level, single servers can
 have more actual perceived uptime for your users.
 
 ### Automated backups **(CORE ONLY)**
@@ -83,7 +83,7 @@ have more actual perceived uptime for your users.
 
 This solution is appropriate for many teams that have the default GitLab installation.
 With automatic backups of the GitLab repositories, configuration, and the database,
-this can be an optimal solution if you don't have strict availability requirements.
+this can be an optimal solution if you don't have strict requirements.
 [Automated backups](../../raketasks/backup_restore.md#configuring-cron-to-make-daily-backups)
 is the least complex to setup. This provides a point-in-time recovery of a predetermined schedule.
 
@@ -100,7 +100,7 @@ shared file server and database systems on the back end. This way, if one of the
 application servers fails, the workflow is not interrupted.
 [HAProxy](https://www.haproxy.org/) is recommended as the load balancer.
 
-With this added availability component you have a number of advantages compared
+With this added component you have a number of advantages compared
 to the default installation:
 
 - Increase the number of users.
@@ -124,7 +124,7 @@ As long as at least one of each component is online and capable of handling the
 > - Supported tiers: [GitLab Premium and Ultimate](https://about.gitlab.com/pricing/)
 
 By adding automatic failover for database systems, you can enable higher uptime
-with an additional database nodes. This extends the default database with a
+with additional database nodes. This extends the default database with
 cluster management and failover policies.
 [PgBouncer](../../development/architecture.md#pgbouncer) in conjunction with
 [Repmgr](../high_availability/database.md) is recommended.
@@ -157,12 +157,12 @@ column.
 | Load balancer(s) ([6](#footnotes)) | Handles load balancing, typically when you have multiple GitLab application services nodes | [Load balancer configuration](../high_availability/load_balancer.md) ([6](#footnotes))      | No |
 | Object storage service ([4](#footnotes)) | Recommended store for shared data objects | [Object Storage configuration](../object_storage.md) | No |
 | NFS ([5](#footnotes)) ([7](#footnotes)) | Shared disk storage service. Can be used as an alternative Object Storage. Required for GitLab Pages | [NFS configuration](../high_availability/nfs.md) | No |
-| [Consul](../../development/architecture.md#consul) ([3](#footnotes)) | Service discovery and health checks/failover | [Consul HA configuration](../high_availability/consul.md) **(PREMIUM ONLY)** | Yes |
+| [Consul](../../development/architecture.md#consul) ([3](#footnotes)) | Service discovery and health checks/failover | [Consul configuration](../high_availability/consul.md) **(PREMIUM ONLY)** | Yes |
 | [PostgreSQL](../../development/architecture.md#postgresql) | Database | [PostgreSQL configuration](https://docs.gitlab.com/omnibus/settings/database.html) | Yes |
 | [PgBouncer](../../development/architecture.md#pgbouncer) | Database connection pooler | [PgBouncer configuration](../high_availability/pgbouncer.md#running-pgbouncer-as-part-of-a-non-ha-gitlab-installation) **(PREMIUM ONLY)** | Yes |
 | Repmgr | PostgreSQL cluster management and failover | [PostgreSQL and Repmgr configuration](../high_availability/database.md) | Yes |
 | [Redis](../../development/architecture.md#redis) ([3](#footnotes))  | Key/value store for fast data lookup and caching | [Redis configuration](../high_availability/redis.md) | Yes |
-| Redis Sentinel | High availability for Redis | [Redis Sentinel configuration](../high_availability/redis.md) | Yes |
+| Redis Sentinel | Redis | [Redis Sentinel configuration](../high_availability/redis.md) | Yes |
 | [Gitaly](../../development/architecture.md#gitaly) ([2](#footnotes)) ([7](#footnotes)) ([10](#footnotes)) | Provides access to Git repositories | [Gitaly configuration](../gitaly/index.md#running-gitaly-on-its-own-server) | Yes |
 | [Sidekiq](../../development/architecture.md#sidekiq) | Asynchronous/background jobs | [Sidekiq configuration](../high_availability/sidekiq.md) | Yes |
 | [GitLab application services](../../development/architecture.md#unicorn)([1](#footnotes)) | Puma/Unicorn, Workhorse, GitLab Shell - serves front-end requests (UI, API, Git over HTTP/SSH) | [GitLab app scaling configuration](../high_availability/gitlab.md) | Yes |
@@ -177,7 +177,7 @@ column.
    on workload.
 
 1. Gitaly node requirements are dependent on customer data, specifically the number of
-   projects and their sizes. We recommend two nodes as an absolute minimum for HA environments
+   projects and their sizes. We recommend two nodes as an absolute minimum,
    and at least four nodes should be used when supporting 50,000 or more users.
    We also recommend that each Gitaly node should store no more than 5TB of data
    and have the number of [`gitaly-ruby` workers](../gitaly/index.md#gitaly-ruby)
@@ -194,7 +194,7 @@ column.
    that you run the Redis Sentinel clusters separately for each Redis Cluster.
 
 1. For data objects such as LFS, Uploads, Artifacts, etc. We recommend an [Object Storage service](../object_storage.md)
-   over NFS where possible, due to better performance and availability.
+   over NFS where possible, due to better performance.
 
 1. NFS can be used as an alternative for object storage but this isn't typically
    recommended for performance reasons. Note however it is required for [GitLab
diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index d14b829bdcc..6d9ab723d2f 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -7,8 +7,8 @@ integrity of all data committed to a repository. GitLab administrators
 can trigger such a check for a project via the project page under the
 admin panel. The checks run asynchronously so it may take a few minutes
 before the check result is visible on the project admin page. If the
-checks failed you can see their output on the admin log page under
-'repocheck.log'.
+checks failed you can see their output on in the [`repocheck.log`
+file.](logs.md#repochecklog)
 
 NOTE: **Note:**
 It is OFF by default because it still causes too many false alarms.
@@ -31,12 +31,10 @@ panel.
 ## What to do if a check failed
 
 If the repository check fails for some repository you should look up the error
-in `repocheck.log`:
+in the [`repocheck.log` file](logs.md#repochecklog) on disk:
 
-- in the [admin panel](logs.md#repochecklog)
-- or on disk, see:
-  - `/var/log/gitlab/gitlab-rails` for Omnibus installations
-  - `/home/git/gitlab/log` for installations from source
+- `/var/log/gitlab/gitlab-rails` for Omnibus installations
+- `/home/git/gitlab/log` for installations from source
 
 If the periodic repository check causes false alarms, you can clear all repository check states by
 navigating to **Admin Area > Settings > Repository**
diff --git a/doc/api/metrics_dashboard_annotations.md b/doc/api/metrics_dashboard_annotations.md
index a4d5985803f..09187a096ef 100644
--- a/doc/api/metrics_dashboard_annotations.md
+++ b/doc/api/metrics_dashboard_annotations.md
@@ -11,6 +11,9 @@ POST /environments/:id/metrics_dashboard/annotations/
 POST /clusters/:id/metrics_dashboard/annotations/
 ```
 
+NOTE: **Note:**
+The value of `dashboard_path` will be treated as a CGI-escaped path, and automatically unescaped.
+
 Parameters:
 
 | Attribute      | Type           | Required | Description                                                                  |
diff --git a/doc/raketasks/README.md b/doc/raketasks/README.md
index 4b77d4952eb..4bba4f2bc5a 100644
--- a/doc/raketasks/README.md
+++ b/doc/raketasks/README.md
@@ -38,3 +38,4 @@ The following are available Rake tasks:
 | [User management](user_management.md)                                                               | Perform user management tasks.                                                            |
 | [Webhooks administration](web_hooks.md)                                                             | Maintain project Webhooks.                                                                |
 | [X.509 signatures](x509_signatures.md)                                                              | Update X.509 commit signatures, useful if certificate store has changed.                  |
+| [Migrate Snippets to Git](migrate_snippets.md)                                                      | Migrate GitLab Snippets to Git repositories and show migration status                     |
diff --git a/doc/raketasks/migrate_snippets.md b/doc/raketasks/migrate_snippets.md
new file mode 100644
index 00000000000..fce91ab703e
--- /dev/null
+++ b/doc/raketasks/migrate_snippets.md
@@ -0,0 +1,96 @@
+# Migration to Versioned Snippets **(CORE ONLY)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215861) in GitLab 13.0.
+
+In GitLab 13.0, [GitLab Snippets are backed by Git repositories](../user/snippets.md#versioned-snippets).
+This means that the snippet content will be stored in the repository
+and users can update it directly through Git.
+
+Nevertheless, existing GitLab Snippets have to be migrated to this new functionality.
+For each snippet, a new repository is created and the snippet content is committed
+to the repository inside a file whose name is the file name used in the snippet
+as well.
+
+GitLab performs this migration through a [Background Migration](../development/background_migrations.md)
+automatically when the GitLab instance is upgrade to 13.0 or a higher version.
+However, if the migration fails for any of the snippets, they still need
+to be migrated individually.
+
+The following Rake tasks will help with that process.
+
+## Migrate specific snippets to Git
+
+In case you want to migrate a range of snippets, run the tasks as described below.
+
+For Omnibus installations, run:
+
+```shell
+sudo gitlab-rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4
+```
+
+For installations from source code, run:
+
+```shell
+bundle exec rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4
+```
+
+There is a default limit (100) to the number of ids supported in the migration
+process. You can modify this limit by using the env variable `LIMIT`.
+
+```shell
+sudo gitlab-rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4 LIMIT=50
+```
+
+For installations from source code, run:
+
+```shell
+bundle exec rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4 LIMIT=50
+```
+
+## Show whether the snippet background migration is running
+
+In case you want to check the status of the snippet background migration,
+whether it is running or not, you can use the following task.
+
+For Omnibus installations, run:
+
+```shell
+sudo gitlab-rake gitlab:snippets:migration_status
+```
+
+For installations from source code, run:
+
+```shell
+bundle exec rake gitlab:snippets:migration_status RAILS_ENV=production
+```
+
+## List non-migrated snippets
+
+With the following task, you can get the ids of all of the snippets
+that haven't been migrated yet or failed to migrate.
+
+For Omnibus installations, run:
+
+```shell
+sudo gitlab-rake gitlab:snippets:list_non_migrated
+```
+
+For installations from source code, run:
+
+```shell
+bundle exec rake gitlab:snippets:list_non_migrated RAILS_ENV=production
+```
+
+As the number of non-migrated snippets can be large, we limit
+by default the size of the number of ids returned to 100. You can
+modify this limit by using the env variable `LIMIT`.
+
+```shell
+sudo gitlab-rake gitlab:snippets:list_non_migrated LIMIT=200
+```
+
+For installations from source code, run:
+
+```shell
+bundle exec rake gitlab:snippets:list_non_migrated RAILS_ENV=production LIMIT=200
+```
diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md
index bc297d5891d..22221531360 100644
--- a/doc/user/project/issues/index.md
+++ b/doc/user/project/issues/index.md
@@ -87,7 +87,7 @@ must be set.
 
 While you can view and manage the full details of an issue on the [issue page](#issue-page),
 you can also work with multiple issues at a time using the [Issues List](#issues-list),
-[Issue Boards](#issue-boards), Issue references, and [Epics](#epics-ultimate)**(ULTIMATE)**.
+[Issue Boards](#issue-boards), Issue references, and [Epics](#epics-premium)**(PREMIUM)**.
 
 Key actions for Issues include:
 
@@ -137,7 +137,7 @@ With [Design Management](design_management.md), you can upload design
 assets to issues and view them all together to easily share and
 collaborate with your team.
 
-### Epics **(ULTIMATE)**
+### Epics **(PREMIUM)**
 
 [Epics](../../group/epics/index.md) let you manage your portfolio of projects more
 efficiently and with less effort by tracking groups of issues that share a theme, across
diff --git a/doc/user/project/issues/issue_data_and_actions.md b/doc/user/project/issues/issue_data_and_actions.md
index 06524f785ab..65e21566d5d 100644
--- a/doc/user/project/issues/issue_data_and_actions.md
+++ b/doc/user/project/issues/issue_data_and_actions.md
@@ -16,7 +16,7 @@ You can find all the information for that issue on one screen.
 - **2.** [To Do](#to-do)
 - **3.** [Assignee](#assignee)
   - **3.1.** [Multiple Assignees **(STARTER)**](#multiple-assignees-starter)
-- **4.** [Epic **(ULTIMATE)**](#epic-ultimate)
+- **4.** [Epic **(PREMIUM)**](#epic-premium)
 - **5.** [Milestone](#milestone)
 - **6.** [Time tracking](#time-tracking)
 - **7.** [Due date](#due-date)
@@ -100,7 +100,7 @@ to track in large teams where there is shared ownership of an issue.
 In [GitLab Starter](https://about.gitlab.com/pricing/), you can
 [assign multiple people](multiple_assignees_for_issues.md) to an issue.
 
-### Epic **(ULTIMATE)**
+### Epic **(PREMIUM)**
 
 You can assign issues to an [Epic](../../group/epics/index.md), which allows better
 management of groups of related issues.