Add latest changes from gitlab-org/gitlab@master

6 files changed, 93 insertions, 63 deletions

diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 6083b9e1dd8..bd986b75142 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1245,12 +1245,14 @@ workers from verifying the same replica concurrently. The worker releases the le
 Praefect contains a background goroutine that releases stale leases every 10 seconds when workers are terminated for
 some reason without releasing the lease.
 
-The worker logs each of the metadata removals prior to executing them. For example:
+The worker logs each of the metadata removals prior to executing them. The `perform_deletions` key
+indicates whether the invalid metadata records are actually deleted or not. For example:
 
 ```json
 {
   "level": "info",
   "msg": "removing metadata records of non-existent replicas",
+  "perform_deletions": false,
   "replicas": {
     "default": {
       "@hashed/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b.git": [
@@ -1261,15 +1263,15 @@ The worker logs each of the metadata removals prior to executing them. For examp
 }
 ```
 
-### Enable verification worker
+### Configure the verification worker
 
-The worker is disabled by default. It can be enabled by configuring the verification interval. The interval
-accepts any valid [Go duration string](https://pkg.go.dev/time#ParseDuration).
+The worker is enabled by default and verifies the metadata records every seven days. The verification
+interval is configurable with any valid [Go duration string](https://pkg.go.dev/time#ParseDuration).
 
-To enable the worker and verify replicas every 7 days:
+To verify the metadata every three days:
 
 ```ruby
-praefect['background_verification_verification_interval'] = '168h'
+praefect['background_verification_verification_interval'] = '72h'
 ```
 
 Values of 0 and below disable the background verifier.
@@ -1278,6 +1280,23 @@ Values of 0 and below disable the background verifier.
 praefect['background_verification_verification_interval'] = '0'
 ```
 
+#### Enable deletions
+
+WARNING:
+Deletions are disabled by default due to a race condition with repository renames that can cause incorrect
+deletions. This is especially prominent in Geo instances as Geo performs more renames than instances without Geo.
+See [Handle repository creations, deletions and renames atomically](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4101)
+for progress on a fix. We do not recommend enabling the deletions until this is fixed.
+
+By default, the worker does not delete invalid metadata records but simply logs them and outputs Prometheus
+metrics for them.
+
+You can enable deleting invalid metadata records with:
+
+```ruby
+praefect['background_verification_delete_invalid_records'] = true
+```
+
 ### Prioritize verification manually
 
 You can prioritize verification of some replicas ahead of their next scheduled verification time.
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 477936d8ed0..2c12f99ad06 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -17994,10 +17994,10 @@ Values for sorting runners.
 | ----- | ----------- |
 | <a id="cirunnerstatusactive"></a>`ACTIVE` **{warning-solid}** | **Deprecated** in 14.6. This was renamed. Use: [`CiRunner.paused`](#cirunnerpaused). |
 | <a id="cirunnerstatusnever_contacted"></a>`NEVER_CONTACTED` | Runner that has never contacted this instance. |
-| <a id="cirunnerstatusoffline"></a>`OFFLINE` **{warning-solid}** | **Deprecated** in 14.6. This field will have a slightly different scope starting in 15.0, with STALE being returned after a certain period offline. |
+| <a id="cirunnerstatusoffline"></a>`OFFLINE` | Runner that has not contacted this instance within the last 2 hours. Will be considered `STALE` if offline for more than 3 months. |
 | <a id="cirunnerstatusonline"></a>`ONLINE` | Runner that contacted this instance within the last 2 hours. |
 | <a id="cirunnerstatuspaused"></a>`PAUSED` **{warning-solid}** | **Deprecated** in 14.6. This was renamed. Use: [`CiRunner.paused`](#cirunnerpaused). |
-| <a id="cirunnerstatusstale"></a>`STALE` | Runner that has not contacted this instance within the last 3 months. Only available if legacyMode is null. Will be a possible return value starting in 15.0. |
+| <a id="cirunnerstatusstale"></a>`STALE` | Runner that has not contacted this instance within the last 3 months. |
 
 ### `CiRunnerType`
 
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 2e104ea79d9..c626ca094fb 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -1433,23 +1433,6 @@ The `merged_by` field in the [merge request API](https://docs.gitlab.com/ee/api/
 
 <div class="deprecation removal-150 breaking-change">
 
-### API: `stale` status returned instead of `offline` or `not_connected`
-
-WARNING:
-This feature will be changed or removed in 15.0
-as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
-Before updating GitLab, review the details carefully to determine if you need to make any
-changes to your code, settings, or workflow.
-
-A breaking change will occur for the Runner [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints in 15.0.
-
-Instead of the GitLab Runner API endpoints returning `offline` and `not_connected` for runners that have not contacted the GitLab instance in the past three months, the API endpoints will return the `stale` value, which was introduced in 14.6.
-
-**Planned removal milestone: <span class="removal-milestone">15.0</span> (2022-05-22)**
-</div>
-
-<div class="deprecation removal-150 breaking-change">
-
 ### CI/CD job name length limit
 
 WARNING:
diff --git a/doc/update/removals.md b/doc/update/removals.md
index b796d70cea9..e1d87ef4616 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -30,6 +30,21 @@ For removal reviewers (Technical Writers only):
 
 ## 15.0
 
+### API: `stale` status returned instead of `offline` or `not_connected`
+
+WARNING:
+This feature was changed or removed in 15.0
+as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
+Before updating GitLab, review the details carefully to determine if you need to make any
+changes to your code, settings, or workflow.
+
+A breaking change was made to the Runner [API](https://docs.gitlab.com/ee/api/runners.html#runners-api) endpoints
+in 15.0.
+
+Instead of the GitLab Runner API endpoints returning `offline` and `not_connected` for runners that have not
+contacted the GitLab instance in the past three months, the API endpoints now return the `stale` value,
+which was introduced in 14.6.
+
 ### Background upload for object storage
 
 WARNING:
diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md
index 18b99e06299..87344e4ff65 100644
--- a/doc/user/application_security/vulnerabilities/index.md
+++ b/doc/user/application_security/vulnerabilities/index.md
@@ -42,7 +42,7 @@ A vulnerability's status can be one of the following:
 | Dismissed | A user has seen this vulnerability and dismissed it because it is not accurate or otherwise not to be resolved. |
 | Resolved  | The vulnerability has been fixed or is no longer present. |
 
-Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an existing vulnerability is no longer detected in a project's `default` branch, you should change its status to Resolved. This ensures that if it is accidentally reintroduced in a future merge, it will be visible again as a new record. You can use the [Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are no longer detected, and [change their status](../vulnerability_report#change-status-of-multiple-vulnerabilities).
+Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an existing vulnerability is no longer detected in a project's `default` branch, you should change its status to Resolved. This ensures that if it is accidentally reintroduced in a future merge, it will be visible again as a new record. You can use the [Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are no longer detected, and [change their status](../vulnerability_report#change-status-of-vulnerabilities).
 
 ## Change vulnerability status
 
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index cda9c4eccf0..e499ddbbd6b 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -34,13 +34,18 @@ in that row:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6165) in GitLab 11.1.
 
-The project-level Vulnerability Report also contains:
+At the project level, the Vulnerability Report also contains:
 
 - A time stamp showing when it was updated, including a link to the latest pipeline.
 - The number of failures that occurred in the most recent pipeline. Select the failure
   notification to view the **Failed jobs** tab of the pipeline's page.
 
-To access the report, navigate to **Security & Compliance > Vulnerability Report**.
+### View the project-level vulnerability report
+
+To view the project-level vulnerability report:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
 
 ## Vulnerability Report actions
 
@@ -56,17 +61,22 @@ From the Vulnerability Report you can:
 
 ## Vulnerability Report filters
 
-You can filter the vulnerabilities table by:
+You can filter the Vulnerability Report to narrow focus on only vulnerabilities matching specific
+criteria.
+
+The available filters are:
 
 <!-- vale gitlab.SubstitutionWarning = NO -->
 
-| Filter   | Available options |
-|:---------|:------------------|
-| Status   | Detected, Confirmed, Dismissed, Resolved. |
-| Severity | Critical, High, Medium, Low, Info, Unknown. |
-| Tool  | For more details, see [Tool filter](#tool-filter). |
-| Project  | For more details, see [Project filter](#project-filter). |
-| Activity | For more details, see [Activity filter](#activity-filter). |
+- **Status**: Detected, Confirmed, Dismissed, Resolved.
+- **Severity**: Critical, High, Medium, Low, Info, Unknown.
+- **Tool**: For more details, see [Tool filter](#tool-filter).
+- **Project**: For more details, see [Project filter](#project-filter).
+- **Activity**: For more details, see [Activity filter](#activity-filter).
+
+The filters' criteria are combined to show only vulnerabilities matching all criteria.
+An exception to this behavior is the Activity filter. For more details about how it works, see
+[Activity filter](#activity-filter).
 
 <!-- vale gitlab.SubstitutionWarning = YES -->
 
@@ -75,7 +85,7 @@ You can filter the vulnerabilities table by:
 To filter the list of vulnerabilities:
 
 1. Select a filter.
-1. Select values from the dropdown.
+1. Select values from the dropdown list.
 1. Repeat the above steps for each desired filter.
 
 After each filter is selected:
@@ -83,11 +93,9 @@ After each filter is selected:
 - The list of matching vulnerabilities is updated.
 - The vulnerability severity totals are updated.
 
-The filters' criteria are combined to show only vulnerabilities matching all criteria.
-An exception to this behavior is the Activity filter. For more details about how it works, see
-[Activity filter](#activity-filter).
+### Tool filter
 
-## Tool filter
+> The third-party tool filter was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229661) in GitLab 13.12.
 
 The tool filter allows you to focus on vulnerabilities detected by selected tools.
 
@@ -95,7 +103,7 @@ When using the tool filter, you can choose:
 
 - **All tools** (default).
 - Individual GitLab-provided tools.
-- Any integrated 3rd-party tool. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229661) in GitLab 13.12.
+- Any integrated third-party tool.
 
 For details of each of the available tools, see [Security scanning tools](../index.md#security-scanning-tools).
 
@@ -103,11 +111,9 @@ For details of each of the available tools, see [Security scanning tools](../ind
 
 The content of the Project filter depends on the current level:
 
-| Level          | Content of the Project filter |
-|:---------------|:------------------------------|
-| Security Center | Only projects you've [added to your personal Security Center](../security_dashboard/index.md#add-projects-to-the-security-center). |
-| Group level    | All projects in the group. |
-| Project level  | Not applicable. |
+- **Security Center**: Only projects you've [added to your personal Security Center](../security_dashboard/index.md#add-projects-to-the-security-center).
+- **Group level**: All projects in the group.
+- **Project level**: Not applicable.
 
 ### Activity filter
 
@@ -119,13 +125,11 @@ all options can be selected in combination.
 
 Selection behavior when using the Activity filter:
 
-| Activity selection                  | Results displayed |
-|:------------------------------------|:------------------|
-|  All                                | Vulnerabilities with any Activity status (same as ignoring this filter). Selecting this deselects any other Activity filter options. |
-|  No activity                        | Only vulnerabilities without either an associated Issue or that are no longer detected. Selecting this deselects any other Activity filter options. |
-|  With issues                        | Only vulnerabilities with one or more associated issues. Does not include vulnerabilities that also are no longer detected. |
-|  No longer detected                 | Only vulnerabilities that are no longer detected in the latest pipeline scan of the `default` branch. Does not include vulnerabilities with one or more associated issues. |
-|  With issues and No longer detected | Only vulnerabilities that have one or more associated issues and also are no longer detected in the latest pipeline scan of the `default` branch. |
+- **All**: Vulnerabilities with any Activity status (same as ignoring this filter). Selecting this deselects any other Activity filter options.
+- **No activity**: Only vulnerabilities without either an associated issue or that are no longer detected. Selecting this deselects any other Activity filter options.
+- **With issues**: Only vulnerabilities with one or more associated issues. Does not include vulnerabilities that also are no longer detected.
+- **No longer detected**: Only vulnerabilities that are no longer detected in the latest pipeline scan of the `default` branch. Does not include vulnerabilities with one or more associated issues.
+- **With issues** and **No longer detected**: Only vulnerabilities that have one or more associated issues and also are no longer detected in the latest pipeline scan of the `default` branch.
 
 ## View details of a vulnerability
 
@@ -155,23 +159,32 @@ If Jira issue support is enabled, the issue link found in the Activity entry lin
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292636) in GitLab 13.10, all statuses became selectable.
 
+From the Vulnerability Report you can change the status of one or more vulnerabilities.
+
 To change the status of vulnerabilities in the table:
 
-1. Select the checkbox for each vulnerability you want to update the status of.
-1. In the dropdown that appears select the desired status, then select **Change status**.
+1. Select the checkbox beside each vulnerability you want to update the status of. To select all,
+   select the checkbox in the table header.
+1. In the **Set status** dropdown list, select the desired status.
+1. Select **Change status**.
 
 ![Project Vulnerability Report](img/project_security_dashboard_status_change_v14_2.png)
 
-### Change status of multiple vulnerabilities
+## Dismissing a vulnerability
+
+When you evaluate a vulnerability and decide it requires no more action, you can mark it
+as **Dismissed**. Dismissed vulnerabilities don't appear in the merge request security widget
+when detected in future scans.
+
+When a vulnerability is dismissed, a record is made of:
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35816) in GitLab 12.9.
+- Who dismissed it.
+- Date and time when it was dismissed.
+- Optionally, a reason why it was dismissed.
 
-You can change the status of multiple vulnerabilities at once:
+Vulnerability records cannot be deleted, so a permanent record always remains.
 
-1. In the list of vulnerabilities, select the checkbox for each vulnerability you want to update.
-   To select all, select the checkbox in the table header.
-1. Above the table, select a new status.
-1. Click **Change status** to save.
+If a vulnerability is dismissed in error, reverse the dismissal by changing its status.
 
 ## Export vulnerability details