Add latest changes from gitlab-org/gitlab@14-8-stable-eev14.8.0-rc42

8 files changed, 17 insertions, 13 deletions

diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md
index 2a301e6ff5b..9ab6235164a 100644
--- a/doc/topics/authentication/index.md
+++ b/doc/topics/authentication/index.md
@@ -1,6 +1,6 @@
 ---
 stage: Manage
-group: Authentication & Authorization
+group: Authentication and Authorization
 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/#assignments
 ---
 
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 177e10b99b9..089f9f8e7cc 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -190,6 +190,9 @@ You can override the default values in the `values.yaml` file in the
   `HELM_UPGRADE_VALUES_FILE` [CI/CD variable](#cicd-variables) with
   the path and name.
 
+Some values can not be overridden with the options above. Settings like `replicaCount` should instead be overridden with the `REPLICAS` 
+[build and deployment](#build-and-deployment) CI/CD variable. Follow [this issue](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/issues/31) for more information.
+
 NOTE:
 For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` variable
 to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--values <my-values.yaml>`.
@@ -433,7 +436,7 @@ applications.
 | `KUBE_NAMESPACE`                        | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). |
 | `KUBECONFIG`                            | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. |
 | `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
-| `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. |
+| `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. Change this variable instead of [modifying](#customize-values-for-helm-chart) `replicaCount`. |
 | `ROLLOUT_RESOURCE_TYPE`                 | Allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. |
 | `ROLLOUT_STATUS_DISABLED`               | From GitLab 12.0, used to disable rollout status check because it does not support all resource types, for example, `cronjob`. |
 | `STAGING_ENABLED`                       | Used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). |
@@ -478,6 +481,7 @@ The following table lists variables used to disable jobs.
 | `brakeman-sast`                        | `SAST_DISABLED`                 |                       | If the variable is present, the job isn't created. |
 | `bundler-audit-dependency_scanning`    | `DEPENDENCY_SCANNING_DISABLED`  |                       | If the variable is present, the job isn't created. |
 | `canary`                               | `CANARY_ENABLED`                |                       | This manual job is created if the variable is present. |
+| `cluster_image_scanning`               | `CLUSTER_IMAGE_SCANNING_DISABLED` |                     | If the variable is present, the job isn't created. |
 | `code_intelligence`                    | `CODE_INTELLIGENCE_DISABLED`    | From GitLab 13.6      | If the variable is present, the job isn't created. |
 | `code_quality`                         | `CODE_QUALITY_DISABLED`         |                       | If the variable is present, the job isn't created. |
 | `container_scanning`                   | `CONTAINER_SCANNING_DISABLED`   |                       | If the variable is present, the job isn't created. |
diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md
index de83ec8b51b..affd746f66f 100644
--- a/doc/topics/cron/index.md
+++ b/doc/topics/cron/index.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Cron syntax is used to schedule when jobs should run.
 
 You may need to use a cron syntax string to
-create a [pipeline schedule](../../api/pipeline_schedules.md#create-a-new-pipeline-schedule),
+create a [pipeline schedule](../../ci/pipelines/schedules.md),
 or to prevent unintentional releases by setting a
 [deploy freeze](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze).
 
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index a94caf2bf33..977f51a7211 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -31,7 +31,7 @@ Documentation for GitLab instance administrators is under [LFS administration do
 
 - Git LFS is supported in GitLab starting with version 8.2
 - Git LFS must be enabled under project settings
-- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up
+- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up must be installed
 
 ## Known limitations
 
diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md
index 2786368a9d7..32e3b6e2f72 100644
--- a/doc/topics/git/lfs/migrate_to_git_lfs.md
+++ b/doc/topics/git/lfs/migrate_to_git_lfs.md
@@ -46,7 +46,7 @@ Before beginning, make sure:
 
 To follow this tutorial, you need:
 
-- The [Maintainer role](../../../user/permissions.md) for the existing Git repository
+- The Maintainer role for the existing Git repository
   you'd like to migrate to LFS with access through the command line.
 - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
   and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp)
diff --git a/doc/topics/git/merge_conflicts.md b/doc/topics/git/merge_conflicts.md
index bf69190030c..47276ccb0b2 100644
--- a/doc/topics/git/merge_conflicts.md
+++ b/doc/topics/git/merge_conflicts.md
@@ -23,7 +23,7 @@ comments: false
 1. Fix conflicts on the `conflicts.rb` file.
 1. Stage the file and continue rebasing.
 1. Force push the changes.
-1. Finally continue with the Merge Request.
+1. Finally continue with the merge request.
 
 ```shell
 git checkout -b conflicts_branch
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index 7675bba8d83..3bca33b32b7 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -71,7 +71,7 @@ For example, many projects do releases but don't need to do hotfixes.
 ## GitHub flow as a simpler alternative
 
 In reaction to Git flow, GitHub created a simpler alternative.
-[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch:
+[GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) has only feature branches and a `main` branch:
 
 ```mermaid
 graph TD
@@ -221,7 +221,7 @@ If the assigned person does not feel comfortable, they can request more changes
 
 In GitLab, it is common to protect the long-lived branches, such as the `main` branch, so [most developers can't modify them](../user/permissions.md).
 So, if you want to merge into a protected branch, assign your merge request to someone with the
-[Maintainer role](../user/permissions.md).
+Maintainer role.
 
 After you merge a feature branch, you should remove it from the source control software.
 In GitLab, you can do this when merging.
@@ -341,7 +341,7 @@ However, as discussed in [the section about rebasing](#squashing-commits-with-re
 
 Rebasing could create more work, as every time you rebase, you may need to resolve the same conflicts.
 Sometimes you can reuse recorded resolutions (`rerere`), but merging is better, because you only have to resolve conflicts once.
-Atlassian has a more thorough explanation of the tradeoffs between merging and rebasing [on their blog](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase).
+Atlassian has [a more thorough explanation of the tradeoffs between merging and rebasing](https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase) on their blog.
 
 A good way to prevent creating many merge commits is to not frequently merge `main` into the feature branch.
 There are three reasons to merge in `main`: utilizing new code, resolving merge conflicts, and updating long-running branches.
@@ -403,7 +403,7 @@ git commit -m 'Properly escape special characters in XML generation'
 
 An example of a good commit message is: "Combine templates to reduce duplicate code in the user views."
 The words "change," "improve," "fix," and "refactor" don't add much information to a commit message.
-For more information about formatting commit messages, please see this excellent [blog post by Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+For more information, please see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 
 To add more context to a commit message, consider adding information regarding the
 origin of the change. For example, the URL of a GitLab issue, or a Jira issue number,
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index 3a0080fe21c..64decba33ad 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -30,8 +30,8 @@ to Kubernetes clusters using the [GitLab Agent](../user/clusters/agent/install/i
 
 #### GitOps deployments **(PREMIUM)**
 
-With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform pull-based
-deployments using Kubernetes manifests. This provides a scalable, secure, and cloud-native
+With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform [pull-based
+deployments of Kubernetes manifests](../user/clusters/agent/repository.md#synchronize-manifest-projects). This provides a scalable, secure, and cloud-native
 approach to manage Kubernetes deployments.
 
 #### Deploy to Kubernetes with the CI/CD Tunnel
@@ -63,4 +63,4 @@ Use GitLab [Releases](../user/project/releases/index.md) to plan, build, and del
 
 ### Feature flags
 
-Use [feature flags](../operations/feature_flags.md) to control and strategically roullout application deployments.
+Use [feature flags](../operations/feature_flags.md) to control and strategically rollout application deployments.