Merge branch 'docs-anchors-19-environments' into 'master'

Docs: Fix anchors related to environments doc

See merge request gitlab-org/gitlab-ce!27082

7 files changed, 10 insertions, 10 deletions

diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index 54493bc2922..eaafc7bc1c0 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -664,7 +664,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs **[PREMIUM]**
 
 Some GitLab [Enterprise Edition](https://about.gitlab.com/pricing/) features can behave differently for each
-environment. For example, you can [create a secret variable to be injected only into a production environment](variables/README.md#limiting-environment-scopes-of-variables-premium).
+environment. For example, you can [create a secret variable to be injected only into a production environment](https://docs.gitlab.com/ee/ci/variables/#limiting-environment-scopes-of-environment-variables-premium).
 
 In most cases, these features use the _environment specs_ mechanism, which offers
 an efficient way to implement scoping within each environment group.
diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
index 908cf85980e..d6ad00a77da 100644
--- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
@@ -511,7 +511,7 @@ Errors can be easily debugged through GitLab's build logs, and within minutes of
 you can see the changes live on your game.
 
 Setting up Continuous Integration and Continuous Deployment from the start with Dark Nova enables
-rapid but stable development. We can easily test changes in a separate [environment](../../../ci/environments.md#introduction-to-environments-and-deployments),
+rapid but stable development. We can easily test changes in a separate [environment](../../environments.md),
 or multiple environments if needed. Balancing and updating a multiplayer game can be ongoing
 and tedious, but having faith in a stable deployment with GitLab CI/CD allows
 a lot of breathing room in quickly getting changes to players.
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index d505f2ae4ce..6055d8c282a 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -127,7 +127,7 @@ displayed by GitLab:
 ![pipeline status](img/pipeline_status.png)
 
 At the end, if anything goes wrong, you can easily
-[roll back](../environments.md#rolling-back-changes) all the changes:
+[roll back](../environments.md#retrying-and-rolling-back) all the changes:
 
 ![rollback button](img/rollback.png)
 
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index 38cd58f11ac..2ffa3d4edc7 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -295,7 +295,7 @@ You can do this straight from the pipeline graph. Just click on the play button
 to execute that particular job.
 
 For example, your pipeline start automatically, but require manual action to
-[deploy to production](environments.md#manually-deploying-to-environments). In the example below, the `production`
+[deploy to production](environments.md#configuring-manual-deployments). In the example below, the `production`
 stage has a job with a manual action.
 
 ![Pipelines example](img/pipelines.png)
@@ -313,7 +313,7 @@ For example, if you start rolling out new code and:
 
 - Users do not experience trouble, GitLab can automatically complete the deployment from 0% to 100%.
 - Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
-  and [rolling](environments.md#rolling-back-changes) back to the last stable version.
+  and [rolling](environments.md#retrying-and-rolling-back) back to the last stable version.
 
 ![Pipelines example](img/pipeline_incremental_rollout.png)
 
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 53651a807c2..2fc1e14f02e 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -33,7 +33,7 @@ In this example, you can see a branch was:
 
 ## How do Review Apps work?
 
-The basis of Review Apps in GitLab is [dynamic environments](../environments.md#dynamic-environments), which allow you to dynamically create a new environment for each branch.
+The basis of Review Apps in GitLab is [dynamic environments](../environments.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch.
 
 Access to the Review App is made available as a link on the [merge request](../../user/project/merge_requests.md) relevant to the branch. Review Apps enable you to review all changes proposed by the merge request in live environment.
 
@@ -60,14 +60,14 @@ To get a better understanding of Review Apps, review documentation on how enviro
 1. Learn about [environments](../environments.md) and their role in the development workflow.
 1. Learn about [CI variables](../variables/README.md) and how they can be used in your CI jobs.
 1. Explore the [`environment` syntax](../yaml/README.md#environment) as defined in `.gitlab-ci.yml`. This will become a primary reference.
-1. Additionally, find out about [manual actions](../environments.md#manually-deploying-to-environments) and how you can use them to deploy to critical environments like production with the push of a button.
+1. Additionally, find out about [manual actions](../environments.md#configuring-manual-deployments) and how you can use them to deploy to critical environments like production with the push of a button.
 1. Follow the [example tutorials](#examples). These will guide you through setting up infrastructure and using Review Apps.
 
 ### Configuring dynamic environments
 
 Configuring Review Apps dynamic environments depends on your technology stack and infrastructure.
 
-For more information, see [dynamic environments](../environments.md#dynamic-environments) documentation to understand how to define and create them.
+For more information, see [dynamic environments](../environments.md#configuring-dynamic-environments) documentation to understand how to define and create them.
 
 ### Creating and destroying Review Apps
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index d52312371cd..cf2189cd00a 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -756,7 +756,7 @@ Manual actions are a special type of job that are not executed automatically,
 they need to be explicitly started by a user. An example usage of manual actions
 would be a deployment to a production environment. Manual actions can be started
 from the pipeline, job, environment, and deployment views. Read more at the
-[environments documentation](../environments.md#manually-deploying-to-environments).
+[environments documentation](../environments.md#configuring-manual-deployments).
 
 Manual actions can be either optional or blocking. Blocking manual actions will
 block the execution of the pipeline at the stage this action is defined in. It's
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 7693109b3c4..9060360e6a2 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -955,7 +955,7 @@ required to go from `10%` to `100%`, you can jump to whatever job you want.
 You can also scale down by running a lower percentage job, just before hitting
 `100%`. Once you get to `100%`, you cannot scale down, and you'd have to roll
 back by redeploying the old version using the
-[rollback button](../../ci/environments.md#rolling-back-changes) in the
+[rollback button](../../ci/environments.md#retrying-and-rolling-back) in the
 environment page.
 
 Below, you can see how the pipeline will look if the rollout or staging