Add latest changes from gitlab-org/gitlab@14-2-stable-ee

4 files changed, 43 insertions, 5 deletions

diff --git a/doc/update/index.md b/doc/update/index.md
index 1289614c181..4b7e63a8277 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -358,6 +358,36 @@ NOTE:
 Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
 and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
 
+### 14.2.0
+
+- Due to an issue where `BatchedBackgroundMigrationWorkers` were
+  [not working](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2785#note_614738345)
+  for self-managed instances, a [fix was created](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65106)
+  and a [14.0.Z](#1400) version was released. If you haven't updated to 14.0.Z, you need
+  to update to at least 14.1.0 that contains the same fix before you update to
+  to 14.2.
+- GitLab 14.2.0 contains background migrations to [address Primary Key overflow risk for tables with an integer PK](https://gitlab.com/groups/gitlab-org/-/epics/4785) for the tables listed below:
+
+  - [`ci_build_needs`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65216)
+  - [`ci_build_trace_chunks`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66123)
+  - [`ci_builds_runner_session`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66433)
+  - [`deployments`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67341)
+  - [`geo_job_artifact_deleted_events`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66763)
+  - [`push_event_payloads`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67299)
+  - `ci_job_artifacts`:
+    - [Finalize job_id conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
+    - [Finalize `ci_job_artifacts` conversion to `bigint`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65601)
+
+  If the migrations are executed as part of a no-downtime deployment, there's a risk of failure due to lock conflicts with the application logic, resulting in lock timeout or deadlocks. In each case, these migrations are safe to re-run until successful:
+
+  ```shell
+  # For Omnibus GitLab
+  sudo gitlab-rake db:migrate
+
+  # For source installations
+  sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
+  ```
+
 ### 14.1.0
 
 - Due to an issue where `BatchedBackgroundMigrationWorkers` were
diff --git a/doc/user/application_security/img/vulnerability-check_v13_4.png b/doc/user/application_security/img/vulnerability-check_v13_4.png
deleted file mode 100644
index 3e38f6eebe7..00000000000
--- a/doc/user/application_security/img/vulnerability-check_v13_4.png
+++ /dev/null
diff --git a/doc/user/application_security/img/vulnerability-check_v14_2.png b/doc/user/application_security/img/vulnerability-check_v14_2.png
new file mode 100644
index 00000000000..655e43221c7
--- /dev/null
+++ b/doc/user/application_security/img/vulnerability-check_v14_2.png
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index 3b0725021ef..50fd727b892 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -194,14 +194,19 @@ merge request would introduce one of the following security issues:
 When the Vulnerability-Check merge request rule is enabled, additional merge request approval
 is required when the latest security report in a merge request:
 
-- Contains a vulnerability of `high`, `critical`, or `unknown` severity that is not present in the
+- Contains vulnerabilities that are not present in the
   target branch. Note that approval is still required for dismissed vulnerabilities.
+- Contains vulnerabilities with severity levels (for example, `high`, `critical`, or `unknown`)
+  matching the rule's severity levels.
+- Contains a vulnerability count higher than the rule allows.
 - Is not generated during pipeline execution.
 
 An approval is optional when the security report:
 
 - Contains no new vulnerabilities when compared to the target branch.
-- Contains only new vulnerabilities of `low` or `medium` severity.
+- Contains only vulnerabilities with severity levels (for example, `low`, `medium`) **NOT** matching
+  the rule's severity levels.
+- Contains a vulnerability count equal to or less than what the rule allows.
 
 When the License-Check merge request rule is enabled, additional approval is required if a merge
 request contains a denied license. For more details, see [Enabling license approvals within a project](../compliance/license_compliance/index.md#enabling-license-approvals-within-a-project).
@@ -219,16 +224,19 @@ Follow these steps to enable `Vulnerability-Check`:
 1. Go to your project and select **Settings > General**.
 1. Expand **Merge request approvals**.
 1. Select **Enable** or **Edit**.
-1. Add or change the **Rule name** to `Vulnerability-Check` (case sensitive).
-1. Set the **No. of approvals required** to greater than zero.
+1. Set the **Security scanners** that the rule applies to.
 1. Select the **Target branch**.
+1. Set the **Vulnerabilities allowed** to the number of vulnerabilities allowed before the rule is
+   triggered.
+1. Set the **Severity levels** to the severity levels that the rule applies to.
+1. Set the **Approvals required** to the number of approvals that the rule requires.
 1. Select the users or groups to provide approval.
 1. Select **Add approval rule**.
 
 Once this group is added to your project, the approval rule is enabled for all merge requests.
 Any code changes cause the approvals required to reset.
 
-![Vulnerability Check Approver Rule](img/vulnerability-check_v13_4.png)
+![Vulnerability Check Approver Rule](img/vulnerability-check_v14_2.png)
 
 ## Using private Maven repositories