Add latest changes from gitlab-org/gitlab@14-5-stable-eev14.5.0-rc42

11 files changed, 62 insertions, 100 deletions

diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index c01ed4a49d0..906fea2e6ad 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -93,6 +93,28 @@ Avoid passing secrets as Docker build arguments if possible, as they may be
 persisted in your image. See
 [this discussion of best practices with secrets](https://github.com/moby/moby/issues/13490) for details.
 
+## Custom container image
+
+By default, [Auto Deploy](stages.md#auto-deploy) deploys a container image built and pushed to the GitLab registry by [Auto Build](stages.md#auto-build).
+You can override this behavior by defining specific variables:
+
+| Entry | Default | Can be overridden by |
+| ----- | -----   | -----    |
+| Image Path | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` for branch pipelines. `$CI_REGISTRY_IMAGE` for tag pipelines. | `$CI_APPLICATION_REPOSITORY` |
+| Image Tag | `$CI_COMMIT_SHA` for branch pipelines. `$CI_COMMIT_TAG` for tag pipelines. | `$CI_APPLICATION_TAG` |
+
+These variables also affect Auto Build. If you don't want to build and push an image to 
+`$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG`, consider
+including only `Jobs/Deploy.gitlab-ci.yml`, or [disabling the `build` jobs](#disable-jobs).
+
+Here is an example setup in your `.gitlab-ci.yml`:
+
+```yaml
+variables:
+  CI_APPLICATION_REPOSITORY: <your-image-repository>
+  CI_APPLICATION_TAG: <the-tag>
+```
+
 ## Extend Auto DevOps with the API
 
 You can extend and manage your Auto DevOps configuration with GitLab APIs:
@@ -218,7 +240,7 @@ See [Multiple Kubernetes clusters for Auto DevOps](multiple_clusters_auto_devops
 
 For clusters not managed by GitLab, you can customize the namespace in
 `.gitlab-ci.yml` by specifying
-[`environment:kubernetes:namespace`](../../ci/environments/index.md#configure-kubernetes-deployments).
+[`environment:kubernetes:namespace`](../../ci/environments/index.md#configure-kubernetes-deployments-deprecated).
 For example, the following configuration overrides the namespace used for
 `production` deployments:
 
@@ -392,6 +414,8 @@ applications.
 | `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). |
 | `CANARY_PRODUCTION_REPLICAS`            | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |
 | `CANARY_REPLICAS`                       | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md). Defaults to 1. |
+| `CI_APPLICATION_REPOSITORY`             | The repository of container image being built or deployed, `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG`. For more details, read [Custom container image](#custom-container-image). |
+| `CI_APPLICATION_TAG`                    | The tag of the container image being built or deployed, `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG`. For more details, read [Custom container image](#custom-container-image). |
 | `DAST_AUTO_DEPLOY_IMAGE_VERSION`        | Customize the image version used for DAST deployments on the default branch. Should usually be the same as `AUTO_DEPLOY_IMAGE_VERSION`. See [list of versions](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/releases). |
 | `DOCKERFILE_PATH`                       | From GitLab 13.2, allows overriding the [default Dockerfile path for the build stage](#custom-dockerfile) |
 | `HELM_RELEASE_NAME`                     | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. |
@@ -399,7 +423,10 @@ applications.
 | `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. |
 | `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. |
+| `KUBE_CONTEXT`                          | From GitLab 14.5, can be used to select which context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) will be used. A context must be selected when using the [CI/CD tunnel](../../user/clusters/agent/ci_cd_tunnel.md). |
 | `KUBE_INGRESS_BASE_DOMAIN`              | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. |
+| `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. |
 | `ROLLOUT_RESOURCE_TYPE`                 | From GitLab 11.9, allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. |
diff --git a/doc/topics/autodevops/multiple_clusters_auto_devops.md b/doc/topics/autodevops/multiple_clusters_auto_devops.md
index 2191ab9ee8b..c6df5ac9e02 100644
--- a/doc/topics/autodevops/multiple_clusters_auto_devops.md
+++ b/doc/topics/autodevops/multiple_clusters_auto_devops.md
@@ -35,8 +35,8 @@ To add a different cluster for each environment:
 1. Navigate to your project's **Infrastructure > Kubernetes clusters**.
 1. Create the Kubernetes clusters with their respective environment scope, as
    described from the table above.
-1. After creating the clusters, navigate to each cluster and [install
-   Ingress](quick_start_guide.md#install-ingress). Wait for the Ingress IP address to be assigned.
+1. After creating the clusters, navigate to each cluster and [install Ingress](quick_start_guide.md#install-ingress).
+   Wait for the Ingress IP address to be assigned.
 1. Make sure you've [configured your DNS](requirements.md#auto-devops-base-domain) with the
    specified Auto DevOps domains.
 1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**,
diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md
index c84b5e4d9c7..1fc2bd7c2c0 100644
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -236,7 +236,7 @@ you to common environment tasks:
   about the Kubernetes cluster and how the application
   affects it in terms of memory usage, CPU usage, and latency
 - **Deploy to** (**{play}** **{angle-down}**) - Displays a list of environments you can deploy to
-- **Terminal** (**{terminal}**) - Opens a [web terminal](../../ci/environments/index.md#web-terminals)
+- **Terminal** (**{terminal}**) - Opens a [web terminal](../../ci/environments/index.md#web-terminals-deprecated)
   session inside the container where the application is running
 - **Re-deploy to environment** (**{repeat}**) - For more information, see
   [Retrying and rolling back](../../ci/environments/index.md#retry-or-roll-back-a-deployment)
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index ead2e957684..039c369ce9b 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -663,7 +663,7 @@ may require commands to be wrapped as follows:
 Some of the reasons you may need to wrap commands:
 
 - Attaching using `kubectl exec`.
-- Using the GitLab [Web Terminal](../../ci/environments/index.md#web-terminals).
+- Using the GitLab [Web Terminal](../../ci/environments/index.md#web-terminals-deprecated).
 
 For example, to start a Rails console from the application root directory, run:
 
diff --git a/doc/topics/git/getting_started.md b/doc/topics/git/getting_started.md
index 7e04eae622f..7a836e5b659 100644
--- a/doc/topics/git/getting_started.md
+++ b/doc/topics/git/getting_started.md
@@ -21,6 +21,12 @@ comments: false
   git clone <url>
   ```
 
+NOTE:
+You can also clone GitLab projects with the
+[GitLab Workflow VS Code extension](../../user/project/repository/vscode.md).
+To learn more, read about the extension's
+[`Git: Clone` command](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow#clone-gitlab-projects).
+
 ## Central Repositories
 
 - To instantiate a central repository a `--bare` flag is required.
diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md
index b09f9fa0f6c..c0bc7ed4e5c 100644
--- a/doc/topics/git/git_rebase.md
+++ b/doc/topics/git/git_rebase.md
@@ -3,13 +3,13 @@ stage: Create
 group: Source Code
 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"
 type: concepts, howto
-description: "Introduction to Git rebase, force-push, and resolving merge conflicts through the command line."
+description: "Introduction to Git rebase and force-push, methods to resolve merge conflicts through the command line."
 ---
 
-# Introduction to Git rebase, force-push, and merge conflicts **(FREE)**
+# Introduction to Git rebase and force-push **(FREE)**
 
 This guide helps you to get started with rebasing, force-pushing, and fixing
-merge conflicts locally.
+[merge conflicts](../../user/project/merge_requests/conflicts.md) locally.
 
 Before diving into this document, make sure you are familiar with using
 [Git through the command line](../../gitlab-basics/start-using-git.md).
@@ -26,7 +26,8 @@ Git. There are the following rebase options:
 
 WARNING:
 `git rebase` rewrites the commit history. It **can be harmful** to do it in
-shared branches. It can cause complex and hard to resolve merge conflicts. In
+shared branches. It can cause complex and hard to resolve
+[merge conflicts](../../user/project/merge_requests/conflicts.md). In
 these cases, instead of rebasing your branch against the default branch,
 consider pulling it instead (`git pull origin master`). It has a similar
 effect without compromising the work of your contributors.
@@ -117,7 +118,7 @@ example, `release-10-3`. You can also replace `origin` with other remote
 repositories, for example, `upstream`. To check what remotes you have linked to your local
 repository, you can run `git remote -v`.
 
-If there are [merge conflicts](#merge-conflicts), Git prompts you to fix
+If there are merge conflicts, Git prompts you to fix
 them before continuing the rebase.
 
 To learn more, check Git's documentation on [rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
@@ -129,7 +130,7 @@ You can rebase your feature branch directly from the merge request through a
 [quick action](../../user/project/quick_actions.md#issues-merge-requests-and-epics),
 if all of these conditions are met:
 
-- No [merge conflicts](#merge-conflicts) exist for your feature branch.
+- No merge conflicts exist for your feature branch.
 - You have the **Developer** role for the source project. This role grants you
   permission to push to the source branch for the source project.
 - If the merge request is in a fork, the fork must allow commits
@@ -144,6 +145,11 @@ To rebase from the UI:
 GitLab schedules a rebase of the feature branch against the default branch and
 executes it as soon as possible.
 
+The user performing the rebase action is considered
+a user that added commits to the merge request. When the merge request approvals setting
+[**Prevent approvals by users who add commits**](../../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits)
+is enabled, this setting prevents the user from also approving the merge request.
+
 ### Interactive rebase
 
 You can use interactive rebase to modify commits. For example, amend a commit
@@ -235,70 +241,3 @@ you can't force push to it unless you either:
   to it.
 
 Then you can force push and protect it again.
-
-## Merge conflicts
-
-As Git is based on comparing versions of a file
-line-by-line, whenever a line changed in your branch coincides with the same
-line changed in the target branch (after the moment you created your feature branch from it), Git
-identifies these changes as a merge conflict. To fix it, you need to choose
-which version of that line you want to keep.
-
-Most conflicts can be [resolved through the GitLab UI](../../user/project/merge_requests/resolve_conflicts.md).
-
-For more complex cases, there are various methods for resolving them. There are
-also [Git GUI apps](https://git-scm.com/downloads/guis) that can help by
-visualizing the differences.
-
-To fix conflicts locally, you can use the following method:
-
-1. Open the terminal and checkout your feature branch, for example, `my-feature-branch`:
-
-   ```shell
-   git checkout my-feature-branch
-   ```
-
-1. [Rebase](#regular-rebase) your branch against the target branch so Git
-   prompts you with the conflicts:
-
-   ```shell
-   git rebase origin/master
-   ```
-
-1. Open the conflicting file in a code editor of your preference.
-1. Look for the conflict block:
-   - It begins with the marker: `<<<<<<< HEAD`.
-   - Below, there is the content with your changes.
-   - The marker: `=======` indicates the end of your changes.
-   - Below, there's the content of the latest changes in the target branch.
-   - The marker `>>>>>>>` indicates the end of the conflict.
-1. Edit the file: choose which version (before or after `=======`) you want to
-   keep, and then delete the portion of the content you don't want in the file.
-1. Delete the markers.
-1. Save the file.
-1. Repeat the process if there are other conflicting files.
-1. Stage your changes:
-
-   ```shell
-   git add .
-   ```
-
-1. Commit your changes:
-
-   ```shell
-   git commit -m "Fix merge conflicts"
-   ```
-
-1. Continue rebasing:
-
-   ```shell
-   git rebase --continue
-   ```
-
-   WARNING:
-   Up to this point, you can run `git rebase --abort` to stop the process.
-   Git aborts the rebase and rolls back the branch to the state you had before
-   running `git rebase`.
-   After you run `git rebase --continue` the rebase **cannot** be aborted.
-
-1. [Force-push](#force-push) to your remote branch.
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 0b4fd335455..b21237203d7 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -42,6 +42,7 @@ Documentation for GitLab instance administrators is under [LFS administration do
   credentials store is recommended.
 - Git LFS always assumes HTTPS so if you have GitLab server on HTTP you must
   [add the URL to Git configuration manually](#troubleshooting).
+- [Group wikis](../../../user/project/wiki/group.md) do not support Git LFS.
 
 NOTE:
 With 8.12 GitLab added LFS support to SSH. The Git LFS communication
diff --git a/doc/topics/index.md b/doc/topics/index.md
index fde420c64f6..6d2c839430b 100644
--- a/doc/topics/index.md
+++ b/doc/topics/index.md
@@ -1,24 +1,9 @@
 ---
-stage: none
-group: unassigned
-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
+redirect_to: '../index.md'
+remove_date: '2022-02-03'
 ---
 
-# Topics
+This document was moved to [another location](../index.md).
 
-Welcome to Topics! We have organized our content resources into topics
-to get you started on areas of your interest. Each topic page
-consists of an index listing all related content. It guides
-you through better understanding GitLab concepts
-through our regular docs, and, when available, through articles (guides,
-tutorials, technical overviews, blog posts) and videos.
-
-- [Auto DevOps](autodevops/index.md)
-- [Authentication](authentication/index.md)
-- [Continuous Integration (GitLab CI/CD)](../ci/index.md)
-- [Cron](cron/index.md)
-- [Git](git/index.md)
-- [GitLab Flow](gitlab_flow.md)
-- [GitLab Installation](../install/index.md)
-- [GitLab Pages](../user/project/pages/index.md)
-- [Offline GitLab](offline/index.md)
+<!-- This redirect file can be deleted after <2022-02-03>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/topics/plan_and_track.md b/doc/topics/plan_and_track.md
index 86c5287b331..abede62c00b 100644
--- a/doc/topics/plan_and_track.md
+++ b/doc/topics/plan_and_track.md
@@ -31,6 +31,7 @@ Get work done as a team.
 - [Labels](../user/project/labels.md)
 - [Milestones](../user/project/milestones/index.md)
 - [Requirements](../user/project/requirements/index.md)
+- [Tasks](../user/tasks.md)
 - [Time tracking](../user/project/time_tracking.md)
 - [Wikis](../user/project/wiki/index.md)
 
diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md
index 31eb7705760..cbd7cfab720 100644
--- a/doc/topics/release_your_application.md
+++ b/doc/topics/release_your_application.md
@@ -4,10 +4,11 @@ group:
 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
 ---
 
-# Release your application **(FREE)**
+# Deploy and release your application **(FREE)**
 
-Release your application internally or to the public. Use
+Deploy your application internally or to the public. Use
 flags to release features incrementally.
 
+- [Environments and deployments](../ci/environments/index.md)
 - [Releases](../user/project/releases/index.md)
 - [Feature flags](../operations/feature_flags.md)
diff --git a/doc/topics/use_gitlab.md b/doc/topics/use_gitlab.md
index f45dc91131c..f73e41c251b 100644
--- a/doc/topics/use_gitlab.md
+++ b/doc/topics/use_gitlab.md
@@ -16,4 +16,6 @@ organize your work, create and secure your application, and analyze its performa
 - [Secure your application](../user/application_security/index.md)
 - [Release your application](release_your_application.md)
 - [Monitor application performance](../operations/index.md)
+- [Monitor runner performance](https://docs.gitlab.com/runner/monitoring/index.html)
+- [Manage your infrastructure](../user/infrastructure/index.md)
 - [Analyze GitLab usage](../user/analytics/index.md)