Fix many 'when manual' anchorsdocs/fix-anchors-for-manual-actions

4 files changed, 5 insertions, 5 deletions

diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 8b3a7b63e62..f4d7b9ad194 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -60,7 +60,7 @@ 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#manual-actions) 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#manually-deploying-to-environments) 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
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index df14376dd36..984878b6c9b 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -776,7 +776,7 @@ In the above example we set up the `review_app` job to deploy to the `review`
 environment, and we also defined a new `stop_review_app` job under `on_stop`.
 Once the `review_app` job is successfully finished, it will trigger the
 `stop_review_app` job based on what is defined under `when`. In this case we
-set it up to `manual` so it will need a [manual action](#manual-actions) via
+set it up to `manual` so it will need a [manual action](#whenmanual) via
 GitLab's web interface in order to run.
 
 The `stop_review_app` job is **required** to have the following keywords defined:
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 436d0a38f31..aac98c6ee7f 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -78,7 +78,7 @@ you can immediately tell that you are navigating to user-related documentation
 about project features; specifically about merge requests. Our site's paths match
 those of our repository, so the clear structure also makes documentation easier to update.
 
-While the documentation is home to a variety of content types, we do not organize by content type.  
+While the documentation is home to a variety of content types, we do not organize by content type.
 For example, do not create groupings of similar media types (e.g. indexes of all articles, videos, etc.).
 Similarly, we do not use glossaries or FAQs. Such grouping of content by type makes
 it difficult to browse for the information you need and difficult to maintain up-to-date content.
@@ -498,7 +498,7 @@ If you want to know the in-depth details, here's what's really happening:
 
 The following GitLab features are used among others:
 
-- [Manual actions](../../ci/yaml/README.md#manual-actions)
+- [Manual actions](../../ci/yaml/README.md#whenmanual)
 - [Multi project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index b4f5a72e148..593eb80e044 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -46,7 +46,7 @@ A. Consider you are a software developer working in a team:
 1. You verify your changes with [JUnit test reports](../../../ci/junit_test_reports.md) in GitLab CI/CD
 1. You request the approval from your manager
 1. Your manager pushes a commit with his final review, [approves the merge request](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html), and set it to [merge when pipeline succeeds](#merge-when-pipeline-succeeds) (Merge Request Approvals are available in GitLab Starter)
-1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#manual-actions) for GitLab CI/CD
+1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD
 1. Your implementations were successfully shipped to your customer
 
 B. Consider you're a web developer writing a webpage for your company's: