Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/labels_select.js

@@ -13,6 +13,7 @@ import ModalStore from './boards/stores/modal_store';
 import boardsStore from './boards/stores/boards_store';
 import { isScopedLabel } from '~/lib/utils/common_utils';
 import initDeprecatedJQueryDropdown from '~/deprecated_jquery_dropdown';
+import { fixTitle } from '~/tooltips';
 
 export default class LabelsSelect {
   constructor(els, options = {}) {
@@ -57,7 +58,6 @@ export default class LabelsSelect {
         .get();
       const scopedLabels = $dropdown.data('scopedLabels');
       const { handleClick } = options;
-      $sidebarLabelTooltip.tooltip();
 
       if ($dropdown.closest('.dropdown').find('.dropdown-new-label').length) {
         new CreateLabelDropdown(
@@ -166,7 +166,8 @@ export default class LabelsSelect {
               labelTooltipTitle = __('Labels');
             }
 
-            $sidebarLabelTooltip.attr('title', labelTooltipTitle).tooltip('_fixTitle');
+            $sidebarLabelTooltip.attr('title', labelTooltipTitle);
+            fixTitle($sidebarLabelTooltip);
 
             $('.has-tooltip', $value).tooltip({
               container: 'body',

app/views/shared/issuable/_sidebar.html.haml

@@ -118,7 +118,7 @@
       - else
         - selected_labels = issuable_sidebar[:labels]
         .block.labels{ data: { qa_selector: 'labels_block' } }
-          .sidebar-collapsed-icon.js-sidebar-labels-tooltip{ title: issuable_labels_tooltip(selected_labels), data: { placement: "left", container: "body", boundary: 'viewport' } }
+          .sidebar-collapsed-icon.has-tooltip.js-sidebar-labels-tooltip{ title: issuable_labels_tooltip(selected_labels), data: { placement: "left", container: "body", boundary: 'viewport' } }
             = sprite_icon('labels')
             %span
               = selected_labels.size

doc/.vale/gitlab/OutdatedVersions.yml

@@ -7,7 +7,7 @@
 extends: existence
 message: 'Can this reference to "%s" be refactored?'
 link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#importance-of-referencing-gitlab-versions-and-tiers
-level: warning
+level: suggestion
 nonword: true
 ignorecase: true
 tokens:

doc/administration/integration/plantuml.md

@@ -132,7 +132,7 @@ stop;
 You need to enable PlantUML integration from Settings under Admin Area. To do
 that, login with an Admin account and do following:
 
-- In GitLab, go to **Admin Area > Settings > Integrations**.
+- In GitLab, go to **Admin Area > Settings > General**.
 - Expand the **PlantUML** section.
 - Check **Enable PlantUML** checkbox.
 - Set the PlantUML instance as `https://gitlab.example.com/-/plantuml/`.

doc/administration/logs.md

@@ -363,8 +363,7 @@ This file lives in `/var/log/gitlab/gitlab-rails/git_json.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/git_json.log` for
 installations from source.
 
-NOTE: **Note:**
+After GitLab version 12.2, this file was renamed from `githost.log` to
-After 12.2, this file was renamed from `githost.log` to
 `git_json.log` and stored in JSON format.
 
 GitLab has to interact with Git repositories, but in some rare cases

doc/administration/monitoring/performance/grafana_configuration.md

@@ -49,7 +49,6 @@ JSON file individually:
 1. After the dashboard is imported, click the **Save dashboard** icon in the top bar:
    ![Grafana save icon](img/grafana_save_icon.png)
 
-   NOTE: **Note:**
    If you don't save the dashboard after importing it, the dashboard is removed
    when you navigate away from the page.
 

doc/administration/packages/container_registry.md

@@ -36,7 +36,7 @@ Otherwise, the Container Registry is not enabled. To enable it:
 - You can configure it for [a different domain](#configure-container-registry-under-its-own-domain).
 
 The Container Registry works under HTTPS by default. You can use HTTP
-but it's not recommended and is out of the scope of this document.
+but it's not recommended and is beyond the scope of this document.
 Read the [insecure Registry documentation](https://docs.docker.com/registry/insecure/)
 if you want to implement this.
 
@@ -77,7 +77,7 @@ Where:
 | `issuer`  | This should be the same value as configured in Registry's `issuer`. Read the [token auth configuration documentation](https://docs.docker.com/registry/configuration/#token). |
 
 A Registry init file is not shipped with GitLab if you install it from source.
-Hence, [restarting GitLab](../restart_gitlab.md#installations-from-source) will not restart the Registry should
+Hence, [restarting GitLab](../restart_gitlab.md#installations-from-source) does not restart the Registry should
 you modify its settings. Read the upstream documentation on how to achieve that.
 
 At the **absolute** minimum, make sure your [Registry configuration](https://docs.docker.com/registry/configuration/#auth)
@@ -101,7 +101,7 @@ If `auth` is not set up, users can pull Docker images without authentication.
 There are two ways you can configure the Registry's external domain. Either:
 
 - [Use the existing GitLab domain](#configure-container-registry-under-an-existing-gitlab-domain).
-  The Registry listens on a port and reuse GitLab's TLS certificate.
+  The Registry listens on a port and reuses GitLab's TLS certificate.
 - [Use a completely separate domain](#configure-container-registry-under-its-own-domain) with a new TLS certificate
   for that domain.
 
@@ -113,16 +113,15 @@ for the first time.
 ### Configure Container Registry under an existing GitLab domain
 
 If the Registry is configured to use the existing GitLab domain, you can
-expose the Registry on a port so that you can reuse the existing GitLab TLS
+expose the Registry on a port. This way you can reuse the existing GitLab TLS
 certificate.
 
-Assuming that the GitLab domain is `https://gitlab.example.com` and the port the
+If the GitLab domain is `https://gitlab.example.com` and the port to the outside world is `5050`, here is what you need to set
-Registry is exposed to the outside world is `5050`, here is what you need to set
 in `gitlab.rb` or `gitlab.yml` if you are using Omnibus GitLab or installed
 GitLab from source respectively.
 
 Ensure you choose a port different than the one that Registry listens to (`5000` by default),
-otherwise there will be conflicts.
+otherwise conflicts occur.
 
 **Omnibus GitLab installations**
 
@@ -180,8 +179,8 @@ docker login gitlab.example.com:5050
 
 ### Configure Container Registry under its own domain
 
-If the Registry is configured to use its own domain, you will need a TLS
+When the Registry is configured to use its own domain, you need a TLS
-certificate for that specific domain (for example, `registry.example.com`) or maybe
+certificate for that specific domain (for example, `registry.example.com`). You might need 
 a wildcard certificate if hosted under a subdomain of your existing GitLab
 domain, for example, `registry.gitlab.example.com`.
 
@@ -272,7 +271,7 @@ Registry application itself.
 
 ## Disable Container Registry for new projects site-wide
 
-If the Container Registry is enabled, then it will be available on all new
+If the Container Registry is enabled, then it should be available on all new
 projects. To disable this function and let the owners of a project to enable
 the Container Registry by themselves, follow the steps below.
 
@@ -308,7 +307,7 @@ the Container Registry by themselves, follow the steps below.
 
 You can configure the Container Registry to use various storage backends by
 configuring a storage driver. By default the GitLab Container Registry
-is configured to use the [filesystem driver](#use-filesystem)
+is configured to use the [file system driver](#use-file-system)
 configuration.
 
 The different supported drivers are:
@@ -327,9 +326,9 @@ Although most S3 compatible services (like [MinIO](https://min.io/)) should work
 Read more about the individual driver's configuration options in the
 [Docker Registry docs](https://docs.docker.com/registry/configuration/#storage).
 
-### Use filesystem
+### Use file system
 
-If you want to store your images on the filesystem, you can change the storage
+If you want to store your images on the file system, you can change the storage
 path for the Container Registry, follow the steps below.
 
 This path is accessible to:
@@ -377,7 +376,7 @@ driver for the Container Registry.
 
 CAUTION: **Warning:**
 GitLab does not back up Docker images that are not stored on the
-filesystem. Enable backups with your object storage provider if
+file system. Enable backups with your object storage provider if
 desired.
 
 **Omnibus GitLab installations**
@@ -436,7 +435,7 @@ you can pull from the Container Registry, but you cannot push.
 1. Optional: To reduce the amount of data to be migrated, run the [garbage collection tool without downtime](#performing-garbage-collection-without-downtime).
 1. This example uses the `aws` CLI. If you haven't configured the
    CLI before, you have to configure your credentials by running `sudo aws configure`.
-   Because a non-admin user likely can't access the Container Registry folder,
+   Because a non-administrator user likely can't access the Container Registry folder,
    ensure you use `sudo`. To check your credential configuration, run
    [`ls`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html) to list
    all buckets.
@@ -468,14 +467,14 @@ you can pull from the Container Registry, but you cannot push.
    sudo aws --endpoint-url https://your-object-storage-backend.com s3 sync registry s3://mybucket --delete --dryrun
    ```
 
-   After verifying the command is going to perform as expected, remove the
+   After verifying the command performs as expected, remove the
    [`--dryrun`](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)
    flag and run the command.
 
    DANGER: **Danger:**
    The [`--delete`](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html)
    flag deletes files that exist in the destination but not in the source.
-   Make sure not to swap the source and destination, or you will delete all data in the Registry.
+   If you swap the source and destination, all data in the Registry is deleted.
 
 1. Verify all Container Registry files have been uploaded to object storage
    by looking at the file count returned by these two commands:
@@ -545,7 +544,7 @@ However, this behavior is undesirable for registries used by internal hosts that
 ### Storage limitations
 
 Currently, there is no storage limitation, which means a user can upload an
-infinite amount of Docker images with arbitrary sizes. This setting will be
+infinite amount of Docker images with arbitrary sizes. This setting should be
 configurable in future releases.
 
 ## Change the registry's internal port
@@ -604,7 +603,7 @@ You can use GitLab as an auth endpoint with an external container registry.
    Container Registry service does not start, even with this enabled.
 
 1. A certificate-key pair is required for GitLab and the external container
-   registry to communicate securely. You will need to create a certificate-key
+   registry to communicate securely. You need to create a certificate-key
    pair, configuring the external container registry with the public
    certificate and configuring GitLab with the private key. To do that, add
    the following to `/etc/gitlab/gitlab.rb`:
@@ -747,7 +746,7 @@ some unused layers, the registry includes a garbage collect command.
 
 GitLab offers a set of APIs to manipulate the Container Registry and aid the process
 of removing unused tags. Currently, this is exposed using the API, but in the future,
-these controls will be migrated to the GitLab interface.
+these controls should migrate to the GitLab interface.
 
 Project maintainers can
 [delete Container Registry tags in bulk](../../api/container_registry.md#delete-registry-repository-tags-in-bulk)
@@ -761,9 +760,9 @@ Prerequisites:
 - You must have installed GitLab by using an Omnibus package or the
   [cloud native chart](https://docs.gitlab.com/charts/charts/registry/#garbage-collection).
 - You must set the Registry to [read-only mode](#performing-garbage-collection-without-downtime).
-  Running garbage collection causes downtime for the Container Registry. If you run this command
+  Running garbage collection causes downtime for the Container Registry. When you run this command
   on an instance in an environment where another instances is still writing to the Registry storage,
-  referenced manifests will be removed.
+  referenced manifests are removed.
 
 ### Understanding the content-addressable layers
 

doc/administration/troubleshooting/elasticsearch.md

@@ -164,7 +164,7 @@ Troubleshooting search result issues is rather straight forward on Elasticsearch
 The first step is to confirm GitLab is using Elasticsearch for the search function.
 To do this:
 
-1. Confirm the integration is enabled in **Admin Area > Settings > Integrations**.
+1. Confirm the integration is enabled in **Admin Area > Settings > General**.
 1. Confirm searches utilize Elasticsearch by accessing the rails console
    (`sudo gitlab-rails console`) and running the following commands:
 

doc/api/feature_flag_user_lists.md

@@ -4,9 +4,10 @@ group: Progressive Delivery
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 ---
 
-# Feature flag user lists API **(PREMIUM)**
+# Feature flag user lists API **(CORE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205409) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205409) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212318) to GitLab Core in 13.5.
 
 API for accessing GitLab Feature Flag User Lists.
 

doc/development/documentation/index.md

@@ -216,9 +216,8 @@ For example, if you move `doc/workflow/lfs/index.md` to
    git grep -n "lfs/lfs_administration"
    ```
 
-NOTE: **Note:**
+1. If the document being moved has any Disqus comments on it, follow the steps
-If the document being moved has any Disqus comments on it, there are extra steps
+   described in [Redirections for pages with Disqus comments](#redirections-for-pages-with-disqus-comments).
-to follow documented just [below](#redirections-for-pages-with-disqus-comments).
 
 Things to note:
 
@@ -249,7 +248,8 @@ using the old URL as value. For example, let's say we moved the document
 available under `https://docs.gitlab.com/my-old-location/README.html` to a new location,
 `https://docs.gitlab.com/my-new-location/index.html`.
 
-Into the **new document** front matter, we add the following:
+Into the **new document** front matter, we add the following information. You must
+include the file name in the `disqus_identifier` URL, even if it's `index.html` or `README.html`.
 
 ```yaml
 ---
@@ -257,9 +257,6 @@ disqus_identifier: 'https://docs.gitlab.com/my-old-location/README.html'
 ---
 ```
 
-Note: it is necessary to include the file name in the `disqus_identifier` URL,
-even if it's `index.html` or `README.html`.
-
 ## Merge requests for GitLab documentation
 
 Before getting started, make sure you read the introductory section
@@ -275,9 +272,8 @@ represents a good-faith effort to follow the template and style standards,
 and is believed to be accurate.
 
 Further needs for what would make the doc even better should be immediately addressed
-in a follow-up MR or issue.
+in a follow-up merge request or issue.
 
-NOTE: **Note:**
 If the release version you want to add the documentation to has already been
 frozen or released, use the label `~"Pick into X.Y"` to get it merged into
 the correct release. Avoid picking into a past release as much as you can, as
@@ -400,8 +396,7 @@ You will need at least Maintainer permissions to be able to run it.
 
 ![Manual trigger a docs build](img/manual_build_docs.png)
 
-NOTE: **Note:**
+You must push a branch to those repositories, as it doesn't work for forks.
-You will need to push a branch to those repositories, it doesn't work for forks.
 
 The `review-docs-deploy*` job will:
 
@@ -418,17 +413,16 @@ minutes and it should appear online, otherwise you can check the status of the
 remote pipeline from the link in the merge request's job output.
 If the pipeline failed or got stuck, drop a line in the `#docs` chat channel.
 
-TIP: **Tip:**
-Someone with no merge rights to the GitLab projects (think of forks from
-contributors) cannot run the manual job. In that case, you can
-ask someone from the GitLab team who has the permissions to do that for you.
-
-NOTE: **Note:**
 Make sure that you always delete the branch of the merge request you were
 working on. If you don't, the remote docs branch won't be removed either,
 and the server where the Review Apps are hosted will eventually be out of
 disk space.
 
+TIP: **Tip:**
+Someone with no merge rights to the GitLab projects (think of forks from
+contributors) cannot run the manual job. In that case, you can
+ask someone from the GitLab team who has the permissions to do that for you.
+
 ### Troubleshooting review apps
 
 In case the review app URL returns 404, follow these steps to debug:

doc/development/geo/framework.md

@@ -197,7 +197,9 @@ For example, to add support for files referenced by a `Widget` model with a
        file_store == ObjectStorage::Store::LOCAL
      end
 
-     def self.replicables_for_geo_node
+     # @param primary_key_in [Range, Widget] arg to pass to primary_key_in scope
+     # @return [ActiveRecord::Relation<Widget>] everything that should be synced to this node, restricted by primary key
+     def self.replicables_for_geo_node(primary_key_in)
        # Should be implemented. The idea of the method is to restrict
        # the set of synced items depending on synchronization settings
      end

doc/development/logging.md

@@ -287,7 +287,6 @@ method or variable shouldn't be evaluated right away)
 See our [HOWTO: Use Sidekiq metadata logs](https://www.youtube.com/watch?v=_wDllvO_IY0) for further knowledge on
 creating visualizations in Kibana.
 
-NOTE: **Note:**
 The fields of the context are currently only logged for Sidekiq jobs triggered
 through web requests. See the
 [follow-up work](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/68)

doc/development/product_analytics/snowplow.md

@@ -54,7 +54,7 @@ Tracking can be enabled at:
 
 We utilize Snowplow for the majority of our tracking strategy and it is enabled on GitLab.com. On a self-managed instance, Snowplow can be enabled by navigating to:
 
-- **Admin Area > Settings > Integrations** in the UI.
+- **Admin Area > Settings > General** in the UI.
 - `admin/application_settings/integrations` in your browser.
 
 The following configuration is required:

doc/development/prometheus_metrics.md

@@ -35,11 +35,6 @@ After you add or change an existing common metric, you must [re-run the import s
 
 Or, you can create a database migration:
 
-NOTE: **Note:**
-If a query metric (which is identified by `id:`) is removed it will not be removed from database by default.
-You might want to add additional database migration that makes a decision what to do with removed one.
-For example: you might be interested in migrating all dependent data to a different metric.
-
 ```ruby
 class ImportCommonMetrics < ActiveRecord::Migration[4.2]
   include Gitlab::Database::MigrationHelpers
@@ -56,6 +51,10 @@ class ImportCommonMetrics < ActiveRecord::Migration[4.2]
 end
 ```
 
+If a query metric (which is identified by `id:`) is removed it will not be removed from database by default.
+You might want to add additional database migration that makes a decision what to do with removed one.
+For example: you might be interested in migrating all dependent data to a different metric.
+
 ## GitLab Prometheus metrics
 
 GitLab provides [Prometheus metrics](../administration/monitoring/prometheus/gitlab_metrics.md)

doc/integration/gitpod.md

@@ -51,7 +51,7 @@ can follow the same steps once the integration has been enabled and configured b
 If you are new to Gitpod, head over to the [Gitpod documentation](https://www.gitpod.io/docs/self-hosted/latest/self-hosted/)
 and get your instance up and running.
 
-1. In GitLab, go to **Admin Area > Settings > Integrations**.
+1. In GitLab, go to **Admin Area > Settings > General**.
 1. Expand the **Gitpod** configuration section.
 1. Check **Enable Gitpod**.
 1. Add your Gitpod instance URL (for example, `https://gitpod.example.com`).

doc/integration/sourcegraph.md

@@ -74,7 +74,7 @@ You can skip this step if you already have your GitLab repositories searchable i
 
 ### Configure your GitLab instance with Sourcegraph
 
-1. In GitLab, go to **Admin Area > Settings > Integrations**.
+1. In GitLab, go to **Admin Area > Settings > General**.
 1. Expand the **Sourcegraph** configuration section.
 1. Check **Enable Sourcegraph**.
 1. Set the Sourcegraph URL to your Sourcegraph instance, e.g., `https://sourcegraph.example.com`.

doc/operations/error_tracking.md

@@ -44,7 +44,6 @@ You may also want to enable Sentry's GitLab integration by following the steps i
 
 ## Error Tracking List
 
-NOTE: **Note:**
 Users with at least Reporter [permissions](../user/permissions.md)
 can find the Error Tracking list at **Operations > Error Tracking** in your project's sidebar.
 Here, you can filter errors by title or by status (one of Ignored , Resolved, or Unresolved) and sort in descending order by Frequency, First Seen, or Last Seen. By default, the error list is ordered by Last Seen and filtered to Unresolved errors.

doc/operations/incident_management/alert_integrations.md

@@ -127,3 +127,26 @@ and details pages.
 If the existing alert is already `resolved`, GitLab creates a new alert instead.
 
 ![Alert Management List](./img/alert_list_v13_1.png)
+
+### Link to your Opsgenie Alerts
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
+
+You can monitor alerts using a GitLab integration with [Opsgenie](https://www.atlassian.com/software/opsgenie).
+
+If you enable the Opsgenie integration, you can't have other GitLab alert
+services, such as [Generic Alerts](generic_alerts.md) or Prometheus alerts,
+active at the same time.
+
+To enable Opsgenie integration:
+
+1. Sign in as a user with Maintainer or Owner [permissions](../../user/permissions.md).
+1. Navigate to **Operations > Alerts**.
+1. In the **Integrations** select box, select **Opsgenie**.
+1. Select the **Active** toggle.
+1. In the **API URL** field, enter the base URL for your Opsgenie integration,
+   such as `https://app.opsgenie.com/alert/list`.
+1. Select **Save changes**.
+
+After you enable the integration, navigate to the Alerts list page at
+**Operations > Alerts**, and then select **View alerts in Opsgenie**.

doc/operations/incident_management/alerts.md

@@ -4,12 +4,16 @@ group: Health
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 ---
 
-# Create and manage alerts in GitLab
+# Alerts
+
+Alerts are a critical entity in your incident managment workflow. They represent a notable event that might indicate a service outage or disruption. GitLab provides a list view for triage and detail view for deeper investigation of what happened.
+
+## Alert List
 
 Users with at least Developer [permissions](../../user/permissions.md) can
-access the Alert Management list at **Operations > Alerts** in your project's
+access the Alert list at **Operations > Alerts** in your project's
-sidebar. The Alert Management list displays alerts sorted by start time, but
+sidebar. The Alert list displays alerts sorted by start time, but
-you can change the sort order by clicking the headers in the Alert Management list.
+you can change the sort order by clicking the headers in the Alert list.
 ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217745) in GitLab 13.1.)
 
 The alert list displays the following information:
@@ -38,66 +42,6 @@ Check out a live example available from the
 [`tanuki-inc` project page](https://gitlab-examples-ops-incident-setup-everyone-tanuki-inc.34.69.64.147.nip.io/)
 in GitLab to examine alerts in action.
 
-## Enable Alerts
-
-There are several ways to accept alerts into your GitLab project. Enabling any
-of these methods enables the Alert list. You need at least Maintainer
-[permissions](../../user/permissions.md) to enable the Alerts feature. After
-configuring alerts, visit **Operations > Alerts** in your project's sidebar to view
-the list of alerts.
-
-### Enable GitLab-managed Prometheus alerts
-
-You can install the GitLab-managed Prometheus application on your Kubernetes
-cluster. For more information, see
-[Managed Prometheus on Kubernetes](../../user/project/integrations/prometheus.md#managed-prometheus-on-kubernetes).
-When GitLab-managed Prometheus is installed, the Alerts list is also enabled.
-
-To populate the alerts with data, see
-[GitLab-Managed Prometheus instances](../metrics/alerts.md#managed-prometheus-instances).
-
-### Enable external Prometheus alerts
-
-You can configure an externally-managed Prometheus instance to send alerts
-to GitLab. To set up this configuration, read the
-[configuring Prometheus](../metrics/alerts.md#external-prometheus-instances)
-documentation. Activating the external Prometheus configuration also enables
-the Alerts list.
-
-To populate the alerts with data, see [External Prometheus instances](../metrics/alerts.md#external-prometheus-instances).
-
-### Enable a Generic Alerts endpoint
-
-GitLab provides the Generic Alerts endpoint so you can accept alerts from a
-third-party alerts service. Read the [instructions for toggling generic alerts](alert_integrations.md#configuration)
-to add this option. After configuring the endpoint, the Alerts list is enabled.
-
-To populate the alerts with data, see [Customizing the payload](alert_integrations.md#customizing-the-payload)
-for requests to the alerts endpoint.
-
-### Opsgenie integration **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
-
-You can monitor alerts using a GitLab integration with [Opsgenie](https://www.atlassian.com/software/opsgenie).
-
-If you enable the Opsgenie integration, you can't have other GitLab alert
-services, such as [Generic Alerts](generic_alerts.md) or Prometheus alerts,
-active at the same time.
-
-To enable Opsgenie integration:
-
-1. Sign in as a user with Maintainer or Owner [permissions](../../user/permissions.md).
-1. Navigate to **Operations > Alerts**.
-1. In the **Integrations** select box, select **Opsgenie**.
-1. Select the **Active** toggle.
-1. In the **API URL** field, enter the base URL for your Opsgenie integration,
-   such as `https://app.opsgenie.com/alert/list`.
-1. Select **Save changes**.
-
-After you enable the integration, navigate to the Alerts list page at
-**Operations > Alerts**, and then select **View alerts in Opsgenie**.
-
 ## Alert severity
 
 Each level of alert contains a uniquely shaped and color-coded icon to help

doc/operations/incident_management/index.md

@@ -58,3 +58,4 @@ For information about GitLab and incident management, see:
 - [Alert details](alert_details.md)
 - [Incidents](incidents.md)
 - [Status page](status_page.md)
+- [Integrations](integrations.md)

doc/operations/incident_management/integrations.md

@@ -0,0 +1,16 @@
+---
+stage: Monitor
+group: Health
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Integrations
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13203) in [GitLab Core](https://about.gitlab.com/pricing/) 12.5.
+
+With Maintainer or higher [permissions](../../user/permissions.md), you can view
+the list of configured alerts integrations by navigating to
+**Settings > Operations** in your project's sidebar menu, and expanding **Alerts** section.
+The list displays the integration name, type, and status (enabled or disabled):
+
+![Current Integrations](img/integrations_list_v13_5.png)

doc/operations/metrics/dashboards/yaml.md

@@ -45,7 +45,6 @@ Read the documentation on [links](index.md#add-related-links-to-custom-dashboard
 
 Dashboards display panel groups in the order they are listed in the dashboard YAML file.
 
-NOTE: **Note:**
 In GitLab versions 13.3 and below, panel groups were ordered by a `priority` key, which
 is no longer used.
 
@@ -60,7 +59,6 @@ Panels in a panel group are laid out in rows consisting of two panels per row. A
 
 Dashboards display panels in the order they are listed in the dashboard YAML file.
 
-NOTE: **Note:**
 In GitLab versions 13.3 and below, panels were ordered by a `weight` key, which
 is no longer used.
 

doc/user/admin_area/settings/project_integration_management.md

@@ -4,40 +4,76 @@ group: Ecosystem
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 ---
 
-# Project integration management **(CORE ONLY)**
+# Project integration management
-
-> [Introduced in](https://gitlab.com/groups/gitlab-org/-/epics/2137) GitLab 13.3.
 
 Project integrations can be configured and enabled by project administrators. As a GitLab instance administrator, you can set default configuration parameters for a given integration that all projects can inherit and use, enabling the integration for all projects that are not already using custom settings.
 
-You can update these default settings at any time, changing the settings in use for all projects that are set to use instance-level defaults. This also enables the integration for all projects on which it was not already enabled.
+You can update these default settings at any time, changing the settings used for all
+projects that are set to use instance-level or group-level defaults. Updating the
+default settings also enables the integration for all projects that didn't have it
+already enabled.
 
-It is only possible to inherit the complete settings for an integration. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137), as well as [group-level management](https://gitlab.com/groups/gitlab-org/-/epics/2543) of integration settings.
+Only the complete settings for an integration can be inherited. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137).
 
-## Manage default settings for a project integration
+## Manage instance-level default settings for a project integration **(CORE ONLY)**
+
+> [Introduced in](https://gitlab.com/groups/gitlab-org/-/epics/2137) GitLab 13.3.
 
 1. Navigate to **Admin Area > Settings > Integrations**.
-1. Select a project integration.
+1. Select an integration.
 1. Enter configuration details and click **Save changes**.
 
 CAUTION: **Caution:**
-This may affect all or most of the projects on your GitLab instance. Please review the details below.
+This may affect all or most of the groups and projects on your GitLab instance. Please review the details below.
 
 If this is the first time you are setting up instance-level settings for an integration:
 
-- The integration is enabled for all projects that do not already have this integration configured if you have the **Enable integration** toggle turned on in the instance-level settings.
+- The integration is enabled for all groups and projects that do not already have this integration configured if you have the **Enable integration** toggle turned on in the instance-level settings.
-- Projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time.
+- Groups and projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time.
 
 When you make further changes to the instance defaults:
 
-- They are immediately applied to all projects that have the integration set to use instance-level default settings.
+- They are immediately applied to all groups and projects that have the integration set to use default settings.
-- They are immediately applied to newer projects, created since you last saved defaults for the integration.
+- They are immediately applied to newer groups and projects, created since you last
-  - If your instance-level default setting has the **Enable integration** toggle turned on, the integration is automatically enabled for all such projects.
+  saved defaults for the integration. If your instance-level default setting has the
-- Projects with custom settings selected for the integration are not immediately affected and may choose to use the latest instance-level defaults at any time.
+  **Enable integration** toggle turned on, the integration is automatically enabled for
+  all such groups and projects.
+- Groups and projects with custom settings selected for the integration are not immediately affected and may choose to use the latest defaults at any time.
 
-It is only possible to inherit the complete settings for an integration. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow instance administrators to update settings inherited by projects without enabling the integration on all non-configured projects by default.
+Only the complete settings for an integration can be inherited. Per-field inheritance
+is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow
+administrators to update settings inherited by groups and projects without enabling the
+integration on all non-configured groups and projects by default.
 
-## Use instance-level default settings for a project integration
+## Manage group-level default settings for a project integration
+
+> [Introduced in](https://gitlab.com/groups/gitlab-org/-/epics/2543) GitLab 13.5.
+
+1. Navigate to the group's **Settings > Integrations**.
+1. Select an integration.
+1. Enter configuration details and click **Save changes**.
+
+CAUTION: **Caution:**
+This may affect all or most of the subgroups and projects belonging to the group. Please review the details below.
+
+If this is the first time you are setting up group-level settings for an integration:
+
+- The integration is enabled for all subgroups and projects belonging to the group that do not already have this integration configured if you have the **Enable integration** toggle turned on in the group-level settings.
+- Subgroups and projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time.
+
+When you make further changes to the group defaults:
+
+- They are immediately applied to all subgroups and projects belonging to the group that have the integration set to use default settings.
+- They are immediately applied to newer subgroups and projects, created since you last saved defaults for the integration.
+  - If your group-level default setting has the **Enable integration** toggle turned on, the integration is automatically enabled for all such subgroups and projects.
+- Subgroups and projects with custom settings selected for the integration are not immediately affected and may choose to use the latest defaults at any time.
+
+Only the complete settings for an integration can be inherited. Per-field inheritance
+is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow
+administrators to update settings inherited by subgroups and projects without enabling the
+integration on all non-configured groups and projects by default.
+
+## Use instance-level or group-level default settings for a project integration
 
 1. Navigate to **Project > Settings > Integrations**.
 1. Choose the integration you want to enable or update.
@@ -45,9 +81,9 @@ It is only possible to inherit the complete settings for an integration. Per-fie
 1. Ensure the toggle is set to **Enable integration**.
 1. Click **Save changes**.
 
-## Use custom settings for a project integration
+## Use custom settings for a group or project integration
 
-1. Navigate to **Project > Settings > Integrations**.
+1. Navigate to project or group's **Settings > Integrations**.
 1. Choose the integration you want to enable or update.
 1. From the drop-down, select **Use custom settings**.
 1. Ensure the toggle is set to **Enable integration** and enter all required settings.

doc/user/clusters/applications.md

@@ -127,7 +127,11 @@ before deploying one.
 The [`runner/gitlab-runner`](https://gitlab.com/gitlab-org/charts/gitlab-runner)
 chart is used to install this application, using
 [a preconfigured `values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/master/values.yaml)
-file. Customizing the installation by modifying this file is not supported.
+file. Customizing the installation by modifying this file is not supported. This
+also means you cannot modify `config.toml` file for this Runner. If you want to
+have that possibility and still deploy Runner in Kubernetes, consider using the
+[Cluster management project](management_project.md) or installing Runner manually
+via [GitLab Runner Helm Chart](https://docs.gitlab.com/runner/install/kubernetes.html).
 
 ### Ingress
 

doc/user/clusters/cost_management.md

@@ -53,3 +53,20 @@ this dashboard.
 You can customize the cost dashboard by editing the `.gitlab/dashboards/default_costs.yml`
 file or creating similar dashboard configuration files. To learn more, read about
 [customizing dashboards in our documentation](/ee/operations/metrics/dashboards/).
+
+#### Available metrics
+
+Metrics contain both instance and node labels. The instance label will be deprecated in a future version.
+
+- `node_cpu_hourly_cost` - Hourly cost per vCPU on this node.
+- `node_gpu_hourly_cost` - Hourly cost per GPU on this node.
+- `node_ram_hourly_cost` - Hourly cost per gigabyte of memory on this node.
+- `node_total_hourly_cost` - Total node cost per hour.
+- `container_cpu_allocation` - Average number of CPUs requested/used over the previous minute.
+- `container_gpu_allocation` - Average number of GPUs requested over the previous minute.
+- `container_memory_allocation_bytes` - Average bytes of RAM requested/used over the previous minute.
+- `pod_pvc_allocation` - Bytes provisioned for a PVC attached to a pod.
+- `pv_hourly_cost` - Hourly cost per GP on a persistent volume.
+
+Some examples are provided in the
+[`kubecost-cost-model` repository](https://gitlab.com/gitlab-examples/kubecost-cost-model/-/blob/master/PROMETHEUS.md#example-queries).

doc/user/clusters/crossplane.md

@@ -78,7 +78,6 @@ provided can manage resources in the `database.crossplane.io` API group:
 See [Configure Your Cloud Provider Account](https://crossplane.github.io/docs/v0.4/cloud-providers.html)
 to configure the installed cloud provider stack with a user account.
 
-NOTE: **Note:**
 The Secret, and the Provider resource referencing the Secret, must be
 applied to the `gitlab-managed-apps` namespace in the guide. Make sure you change that
 while following the process.

doc/user/group/index.md

@@ -697,6 +697,7 @@ To enable prevent project forking:
 - **Audit Events**: View [Audit Events](../../administration/audit_events.md)
   for the group. **(STARTER ONLY)**
 - **Pipelines quota**: Keep track of the [pipeline quota](../admin_area/settings/continuous_integration.md) for the group.
+- **Integrations**: Configure [integrations](../admin_area/settings/project_integration_management.md) for your group.
 
 #### Storage usage quota **(STARTER)**
 

doc/user/packages/composer_repository/index.md

@@ -12,6 +12,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Publish [Composer](https://getcomposer.org/) packages in your project's Package Registry.
 Then, install the packages whenever you need to use them as a dependency.
 
+Only Composer 1.x is supported. Consider contributing or even adding support for
+[Composer 2.0 in the Package Registry](https://gitlab.com/gitlab-org/gitlab/-/issues/259840).
+
 ## Create a Composer package
 
 If you do not have a Composer package, create one and check it in to

doc/user/project/clusters/add_eks_clusters.md

@@ -43,7 +43,7 @@ For example, the following policy document allows assuming a role whose name sta
 
 Generate an access key for the IAM user, and configure GitLab with the credentials:
 
-1. Navigate to **Admin Area > Settings > Integrations** and expand the **Amazon EKS** section.
+1. Navigate to **Admin Area > Settings > General** and expand the **Amazon EKS** section.
 1. Check **Enable Amazon EKS integration**.
 1. Enter the account ID and access key credentials into the respective
    `Account ID`, `Access key ID` and `Secret access key` fields.

doc/user/project/clusters/serverless/aws.md

@@ -377,7 +377,6 @@ To set these:
    `AWS_SECRET_ACCESS_KEY`.
 1. Mask the credentials so they do not show in logs using the **Masked** toggle.
 
-NOTE: **Note:**
 The AWS credentials you provide must include IAM policies that provision correct access
 control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
 

doc/user/project/deploy_boards.md

@@ -42,9 +42,8 @@ knowledge. In particular, you should be familiar with:
 - [Kubernetes canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
 
 NOTE: **Note:**
-In GitLab 13.4 and earlier, apps that consist of multiple deployments are shown as
+Apps that consist of multiple deployments are shown as duplicates on the deploy board.
-duplicates on the deploy board. This is [fixed](https://gitlab.com/gitlab-org/gitlab/-/issues/8463)
+Follow [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/8463) for details.
-in GitLab 13.5.
 
 ## Use cases
 

doc/user/project/integrations/prometheus.md

@@ -173,10 +173,7 @@ one of them will be used:
 > - GitLab 9.3 added the [numeric comparison](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/27439) of the 30 minute averages.
 
 Developers can view the performance impact of their changes within the merge
-request workflow.
+request workflow. This feature requires [Kubernetes](prometheus_library/kubernetes.md) metrics.
-
-NOTE: **Note:**
-Requires [Kubernetes](prometheus_library/kubernetes.md) metrics.
 
 When a source branch has been deployed to an environment, a sparkline and
 numeric comparison of the average memory consumption will appear. On the

doc/user/project/labels.md

@@ -155,7 +155,7 @@ by preventing certain labels from being used together.
 A label is scoped when it uses a special double-colon (`::`) syntax in the label’s
 title, for example:
 
-![Sample scoped labels](img/labels_key_value_v12_1.png)
+![Scoped labels](img/labels_key_value_v13_5.png)
 
 An issue, merge request or epic cannot have two scoped labels, of the form `key::value`,
 with the same `key`. Adding a new label with the same `key`, but a different `value` will
@@ -214,7 +214,7 @@ issue, or merge request.
 If you are subscribing to a group label from within a project, you can select to subscribe
 to label notifications for the project only, or the whole group.
 
-![Labels subscriptions](img/labels_subscriptions_v12_1.png)
+![Labels subscriptions](img/labels_subscriptions_v13_5.png)
 
 ## Label priority
 
@@ -228,7 +228,7 @@ from the group label list.
 
 From the project label list page, star a label to indicate that it has a priority.
 
-![Labels prioritized](img/labels_prioritized_v12_1.png)
+![Labels prioritized](img/labels_prioritized_v13_5.png)
 
 Drag starred labels up and down the list to change their priority, where higher in the list
 means higher priority.

package.json

@@ -43,7 +43,7 @@
     "@babel/preset-env": "^7.10.1",
     "@gitlab/at.js": "1.5.5",
     "@gitlab/svgs": "1.171.0",
-    "@gitlab/ui": "21.25.0",
+    "@gitlab/ui": "21.27.0",
     "@gitlab/visual-review-tools": "1.6.1",
     "@rails/actioncable": "^6.0.3-3",
     "@rails/ujs": "^6.0.3-2",

yarn.lock

@@ -866,10 +866,10 @@
   resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.171.0.tgz#abc3092bf804f0898301626130e0f3231834924a"
   integrity sha512-TPfdqIxQDda+0CQHhb9XdF50lmqDmADu6yT8R4oZi6BoUtWLdiHbyFt+RnVU6t7EmjIKicNAii7Ga+f2ljCfUA==
 
-"@gitlab/ui@21.25.0":
+"@gitlab/ui@21.27.0":
-  version "21.25.0"
+  version "21.27.0"
-  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-21.25.0.tgz#993f7c179ffdcb6a421057cdb82de1a8bdc27d76"
+  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-21.27.0.tgz#4463adc552bb7b7f9a22e0a0281ca761a3daa70a"
-  integrity sha512-UoBfxQTOugSAEBeoCPQCcZKc0JAKKcAMLunPkaATh9A2lo1oAyGp0EnW4607dDiceDkG78BZXxmTQ2UEtkiU5g==
+  integrity sha512-9bMZZebdXWXhPnXbklcragfGosNwZEcqulITWvPSwXcFJwNk2xEHpKy7b/SwQMcErpDjne/eduEnWEGtT+aFNw==
   dependencies:
     "@babel/standalone" "^7.0.0"
     "@gitlab/vue-toasted" "^1.3.0"