Add latest changes from gitlab-org/gitlab@master

13 files changed, 100 insertions, 74 deletions

diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index d70e9d1baa5..3ad411f6f5a 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -115,10 +115,10 @@ following attributes:
   `source_code_management` category.
 - `has_external_dependencies` - whether or not the queue connects to external
   services. For example, all importers have this set to `true`.
-- `latency_sensitive` - whether or not the queue is particularly sensitive to
-  latency, which also means that its jobs should run quickly. For example, the
-  `authorized_projects` queue is used to refresh user permissions, and is
-  latency sensitive.
+- `urgency` - how important it is that this queue's jobs run
+  quickly. Can be `high`, `default`, or `none`. For example, the
+  `authorized_projects` queue is used to refresh user permissions, and
+  is high urgency.
 - `name` - the queue name. The other attributes are typically more useful as
   they are more general, but this is available in case a particular queue needs
   to be selected.
@@ -126,9 +126,9 @@ following attributes:
   `unknown`. For example, the `project_export` queue is memory bound as it has
   to load data in memory before saving it for export.
 
-Both `has_external_dependencies` and `latency_sensitive` are boolean attributes:
-only the exact string `true` is considered true, and everything else is
-considered false.
+`has_external_dependencies` is a boolean attribute: only the exact
+string `true` is considered true, and everything else is considered
+false.
 
 ### Available operators
 
@@ -162,10 +162,10 @@ In `/etc/gitlab/gitlab.rb`:
 sidekiq_cluster['enable'] = true
 sidekiq_cluster['experimental_queue_selector'] = true
 sidekiq_cluster['queue_groups'] = [
-  # Run all non-CPU-bound queues that are latency sensitive
-  'resource_boundary!=cpu&latency_sensitive=true',
-  # Run all continuous integration and pages queues that are not latency sensitive
-  'feature_category=continuous_integration,pages&latency_sensitive=false'
+  # Run all non-CPU-bound queues that are high urgency
+  'resource_boundary!=cpu&urgency=high,
+  # Run all continuous integration and pages queues that are not high urgency
+  'feature_category=continuous_integration,pages&urgency!=high
 ]
 ```
 
diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql
index 8d6fc859ca2..75d94f58605 100644
--- a/doc/api/graphql/reference/gitlab_schema.graphql
+++ b/doc/api/graphql/reference/gitlab_schema.graphql
@@ -1939,11 +1939,6 @@ type Epic implements Noteable {
   hasIssues: Boolean!
 
   """
-  Current health status. Available only when feature flag save_issuable_health_status is enabled.
-  """
-  healthStatus: HealthStatus
-
-  """
   ID of the epic
   """
   id: ID!
@@ -7813,11 +7808,6 @@ input UpdateEpicInput {
   groupPath: ID!
 
   """
-  The desired health status
-  """
-  healthStatus: HealthStatus
-
-  """
   The iid of the epic to mutate
   """
   iid: ID!
diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json
index 4f2cbe81781..9434c15b681 100644
--- a/doc/api/graphql/reference/gitlab_schema.json
+++ b/doc/api/graphql/reference/gitlab_schema.json
@@ -24544,16 +24544,6 @@
               "defaultValue": null
             },
             {
-              "name": "healthStatus",
-              "description": "The desired health status",
-              "type": {
-                "kind": "ENUM",
-                "name": "HealthStatus",
-                "ofType": null
-              },
-              "defaultValue": null
-            },
-            {
               "name": "clientMutationId",
               "description": "A unique identifier for the client performing the mutation.",
               "type": {
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 1a9be3f496b..9d1d95ff2fb 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -307,7 +307,6 @@ Represents an epic.
 | `group` | Group! | Group to which the epic belongs |
 | `hasChildren` | Boolean! | Indicates if the epic has children |
 | `hasIssues` | Boolean! | Indicates if the epic has direct issues |
-| `healthStatus` | HealthStatus | Current health status. Available only when feature flag save_issuable_health_status is enabled. |
 | `id` | ID! | ID of the epic |
 | `iid` | ID! | Internal ID of the epic |
 | `parent` | Epic | Parent epic of the epic |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 255ae3f7c13..7fbaf5ca0b8 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -2090,9 +2090,8 @@ job:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20390) in
 GitLab 11.2. Requires GitLab Runner 11.2 and above.
 
-The `reports` keyword is used for collecting test reports from jobs and
-exposing them in GitLab's UI (merge requests, pipeline views). Read how to use
-this with [JUnit reports](#artifactsreportsjunit).
+The `reports` keyword is used for collecting test reports, code quality reports, and security reports from jobs.
+It also exposes these reports in GitLab's UI (merge requests, pipeline views, and security dashboards).
 
 NOTE: **Note:**
 The test reports are collected regardless of the job results (success or failure).
diff --git a/doc/development/licensing.md b/doc/development/licensing.md
index 2dc77b2eec8..a716db6b407 100644
--- a/doc/development/licensing.md
+++ b/doc/development/licensing.md
@@ -46,8 +46,8 @@ More detailed information on how the gem and its commands work is available in t
 
 Libraries with the following licenses are acceptable for use:
 
-- [The MIT License](https://choosealicense.com/licenses/mit/) (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
-- [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) (version 2, version 3): GPL constraints regarding modification and redistribution under the same license are not required of projects using an LGPL library, only upon modification of the LGPL-licensed library itself.
+- [MIT License](https://choosealicense.com/licenses/mit/) (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
+- [GNU Lesser General Public License (GNU LGPL)](https://choosealicense.com/licenses/lgpl-3.0/) (version 2, version 3): GPL constraints regarding modification and redistribution under the same license are not required of projects using an LGPL library, only upon modification of the LGPL-licensed library itself.
 - [Apache 2.0 License](https://choosealicense.com/licenses/apache-2.0/): A permissive license that also provides an express grant of patent rights from contributors to users.
 - [Ruby 1.8 License][ruby-1.8]: Dual-licensed under either itself or the GPLv2, defer to the Ruby License itself. Acceptable because of point 3b: "You may distribute the software in object code or binary form, provided that you do at least ONE of the following: b) accompany the distribution with the machine-readable source of the software."
 - [Ruby 1.9 License][ruby-1.9]: Dual-licensed under either itself or the BSD 2-Clause License, defer to BSD 2-Clause.
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index e15daab0fdb..89a05f91a9e 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -121,7 +121,30 @@ NOTE: **Note:**
 Note that a cop will fail if the worker class is not marked as idempotent.
 Consider skipping the cop if you're not confident your job can safely run multiple times.
 
-## Latency Sensitive Jobs
+## Job urgency
+
+Jobs can have an `urgency` attribute set, which can be `:high`,
+`:default`, or `:none`. These have the below targets:
+
+| **Urgency** | **Queue Scheduling Target** | **Execution Latency Requirement**  |
+|-------------|-----------------------------|------------------------------------|
+| `:high`     | 100 milliseconds            | p50 of 1 second, p99 of 10 seconds |
+| `:default`  | 1 minute                    | Maximum run time of 1 hour         |
+| `:none`     | None                        | Maximum run time of 1 hour         |
+
+To set a job's urgency, use the `urgency` class method:
+
+```ruby
+class HighUrgencyWorker
+  include ApplicationWorker
+
+  urgency :high
+
+  # ...
+end
+```
+
+### Latency sensitive jobs
 
 If a large number of background jobs get scheduled at once, queueing of jobs may
 occur while jobs wait for a worker node to be become available. This is normal
@@ -140,7 +163,7 @@ of these jobs include:
 When these jobs are delayed, the user may perceive the delay as a bug: for
 example, they may push a branch and then attempt to create a merge request for
 that branch, but be told in the UI that the branch does not exist. We deem these
-jobs to be `latency_sensitive`.
+jobs to be `urgency :high`.
 
 Extra effort is made to ensure that these jobs are started within a very short
 period of time after being scheduled. However, in order to ensure throughput,
@@ -150,31 +173,11 @@ these jobs also have very strict execution duration requirements:
 1. 99% of jobs should complete within 10 seconds.
 
 If a worker cannot meet these expectations, then it cannot be treated as a
-`latency_sensitive` worker: consider redesigning the worker, or splitting the
-work between two different workers, one with `latency_sensitive` code that
-executes quickly, and the other with non-`latency_sensitive`, which has no
+`urgency :high` worker: consider redesigning the worker, or splitting the
+work between two different workers, one with `urgency :high` code that
+executes quickly, and the other with `urgency :default`, which has no
 execution latency requirements (but also has lower scheduling targets).
 
-This can be summed up in the following table:
-
-| **Latency Sensitivity** | **Queue Scheduling Target** | **Execution Latency Requirement**   |
-|-------------------------|-----------------------------|-------------------------------------|
-| Not `latency_sensitive` | 1 minute                    | Maximum run time of 1 hour          |
-| `latency_sensitive`     | 100 milliseconds            | p50 of 1 second, p99 of 10 seconds  |
-
-To mark a worker as being `latency_sensitive`, use the
-`latency_sensitive_worker!` attribute, as shown in this example:
-
-```ruby
-class LatencySensitiveWorker
-  include ApplicationWorker
-
-  latency_sensitive_worker!
-
-  # ...
-end
-```
-
 ## Jobs with External Dependencies
 
 Most background jobs in the GitLab application communicate with other GitLab
@@ -194,7 +197,7 @@ the background processing cluster in several ways:
    therefore we cannot guarantee the execution latencies on these jobs. Since we
    cannot guarantee execution latency, we cannot ensure throughput and
    therefore, in high-traffic environments, we need to ensure that jobs with
-   external dependencies are separated from `latency_sensitive` jobs, to ensure
+   external dependencies are separated from high urgency jobs, to ensure
    throughput on those queues.
 1. Errors in jobs with external dependencies have higher alerting thresholds as
    there is a likelihood that the cause of the error is external.
@@ -212,7 +215,7 @@ class ExternalDependencyWorker
 end
 ```
 
-NOTE: **Note:** Note that a job cannot be both latency sensitive and have
+NOTE: **Note:** Note that a job cannot be both high urgency and have
 external dependencies.
 
 ## CPU-bound and Memory-bound Workers
@@ -246,14 +249,14 @@ bespoke low concurrency, high memory fleet.
 
 Note that memory-bound workers create heavy GC workloads, with pauses of
 10-50ms. This will have an impact on the latency requirements for the
-worker. For this reason, `memory` bound, `latency_sensitive` jobs are not
+worker. For this reason, `memory` bound, `urgency :high` jobs are not
 permitted and will fail CI. In general, `memory` bound workers are
 discouraged, and alternative approaches to processing the work should be
 considered.
 
-If a worker needs large amounts of both memory and CPU time, it should be marked as
-memory-bound, due to the above restrction on latency-sensitive memory-bound
-workers.
+If a worker needs large amounts of both memory and CPU time, it should
+be marked as memory-bound, due to the above restrction on high urgency
+memory-bound workers.
 
 ## Declaring a Job as CPU-bound
 
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index f39151cfa59..ef8676ddf32 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -44,9 +44,8 @@ On our CI, we use [rspec-retry] to automatically retry a failing example a few
 times (see [`spec/spec_helper.rb`] for the precise retries count).
 
 We also use a home-made `RspecFlaky::Listener` listener which records flaky
-examples in a JSON report file on `master` (`retrieve-tests-metadata` and `update-tests-metadata` jobs), and warns when a new flaky example
-is detected in any other branch (`flaky-examples-check` job). In the future, the
-`flaky-examples-check` job will not be allowed to fail.
+examples in a JSON report file on `master` (`retrieve-tests-metadata` and
+`update-tests-metadata` jobs).
 
 This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13021>.
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index b09dba573f2..8aad15671e1 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -73,9 +73,13 @@ Without group-managed accounts, users can link their SAML identity with any exis
 When this option is enabled:
 
 - All existing and new users in the group will be required to log in via the SSO URL associated with the group.
-- On successfully authenticating, GitLab will prompt the user to create a new, dedicated account using the email address received from the configured identity provider.
 - After the group-managed account has been created, group activity will require the use of this user account.
 
+Upon successful authentication, GitLab prompts the user with options, based on the email address received from the configured identity provider:
+
+- To create a unique account with the newly received email address.
+- If the received email address matches one of the user's verified GitLab email addresses, the option to convert the existing account to a group-managed account. ([Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/13481).)
+
 Since use of the group-managed account requires the use of SSO, users of group-managed accounts will lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
 
 - The user will be unable to access the group (their credentials will no longer work on the identity provider when prompted to SSO).
diff --git a/doc/user/incident_management/index.md b/doc/user/incident_management/index.md
index c644c5801df..880083bf815 100644
--- a/doc/user/incident_management/index.md
+++ b/doc/user/incident_management/index.md
@@ -65,6 +65,11 @@ alert is resolved.
 Metrics can be embedded anywhere where GitLab Markdown is used, for example,
 descriptions and comments on issues and merge requests.
 
+This can be useful for when you're sharing metrics, such as for discussing
+an incident or performance issues, so you can output the dashboard directly
+into any issue, merge request, epic, or any other Markdown text field in GitLab
+by simply [copying and pasting the link to the metrics dashboard](../project/integrations/prometheus.md#embedding-gitlab-managed-kubernetes-metrics).
+
 TIP: **Tip:**
 Both GitLab-hosted and Grafana metrics can also be
 [embedded in issue templates](../project/integrations/prometheus.md#embedding-metrics-in-issue-templates).
@@ -73,6 +78,32 @@ Both GitLab-hosted and Grafana metrics can also be
 
 Learn how to embed [GitLab hosted metric charts](../project/integrations/prometheus.md#embedding-metric-charts-within-gitlab-flavored-markdown).
 
+#### Context menu
+
+From each of the embedded metrics panels, you can access more details
+about the data you are viewing from a context menu.
+
+You can access the context menu by clicking the **{ellipsis_v}** **More actions**
+dropdown box above the upper right corner of the panel:
+
+The options are:
+
+- [View logs](#view-logs-ultimate) **(ULTIMATE)**
+- [Download CSV](#download-csv)
+
+##### View logs **(ULTIMATE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/201846) in GitLab Ultimate 12.8.
+
+This can be useful if you are triaging an application incident and need to
+[explore logs](../project/integrations/prometheus.md#view-pod-logs-ultimate)
+from across your application. It also helps you to understand
+what is affecting your application's performance and quickly resolve any problems.
+
+##### Download CSV
+
+Data from embedded charts can be [downloaded as CSV](../project/integrations/prometheus.md#downloading-data-as-csv).
+
 ### Grafana metrics
 
 Learn how to embed [Grafana hosted metric charts](../project/integrations/prometheus.md#embedding-grafana-charts).
diff --git a/doc/user/project/integrations/img/embedded_metrics_markdown_v12_8.png b/doc/user/project/integrations/img/embedded_metrics_markdown_v12_8.png
new file mode 100644
index 00000000000..ffd34705464
--- /dev/null
+++ b/doc/user/project/integrations/img/embedded_metrics_markdown_v12_8.png
diff --git a/doc/user/project/integrations/img/embedded_metrics_rendered_v12_8.png b/doc/user/project/integrations/img/embedded_metrics_rendered_v12_8.png
new file mode 100644
index 00000000000..b024daaaa8e
--- /dev/null
+++ b/doc/user/project/integrations/img/embedded_metrics_rendered_v12_8.png
diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md
index 2f1be1c2257..bbe2f88795e 100644
--- a/doc/user/project/integrations/prometheus.md
+++ b/doc/user/project/integrations/prometheus.md
@@ -561,7 +561,9 @@ The options are:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/122013) in GitLab 12.8.
 
-If you have [Kubernetes Pod Logs](../clusters/kubernetes_pod_logs.md) enabled, you can navigate from the charts in the dashboard to view Pod Logs by clicking on the context menu in the upper-right corner.
+If you have [Pod Logs](../clusters/kubernetes_pod_logs.md) enabled,
+you can navigate from the charts in the dashboard to view Pod Logs by
+clicking on the context menu in the upper-right corner.
 
 If you use the **Timeline zoom** function at the bottom of the chart, logs will narrow down to the time range you selected.
 
@@ -677,10 +679,19 @@ Prometheus server.
 
 It is possible to display metrics charts within [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm). The maximum number of embeds allowed in a GitLab Flavored Markdown field is 100.
 
+This can be useful if you are sharing an application incident or performance
+metrics to others and want to have relevant information directly available.
+
 NOTE: **Note:**
 Requires [Kubernetes](prometheus_library/kubernetes.md) metrics.
 
-To display a metric chart, include a link of the form `https://<root_url>/<project>/-/environments/<environment_id>/metrics`.
+To display metric charts, include a link of the form `https://<root_url>/<project>/-/environments/<environment_id>/metrics`:
+
+![Embedded Metrics Markdown](img/embedded_metrics_markdown_v12_8.png)
+
+GitLab unfurls the link as an embedded metrics panel:
+
+![Embedded Metrics Rendered](img/embedded_metrics_rendered_v12_8.png)
 
 A single chart may also be embedded. You can generate a link to the chart via the dropdown located on the right side of the chart: