Docs: Fix missed or newly added broken anchors

doc/api/commits.md

@@ -475,7 +475,7 @@ GET /projects/:id/repository/commits/:sha/statuses
 | `sha`     | string  | yes | The commit SHA
 | `ref`     | string  | no  | The name of a repository branch or tag or, if not given, the default branch
 | `stage`   | string  | no  | Filter by [build stage](../ci/yaml/README.md#stages), e.g., `test`
-| `name`    | string  | no  | Filter by [job name](../ci/yaml/README.md#jobs), e.g., `bundler:audit`
+| `name`    | string  | no  | Filter by [job name](../ci/yaml/README.md#introduction), e.g., `bundler:audit`
 | `all`     | boolean | no  | Return all statuses, not only the latest ones
 
 ```bash

doc/api/releases/links.md

@@ -15,7 +15,7 @@ GET /projects/:id/releases/:tag_name/assets/links
 
 | Attribute     | Type           | Required | Description                             |
 | ------------- | -------------- | -------- | --------------------------------------- |
-| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
 | `tag_name`    | string         | yes      | The tag associated with the Release. |
 
 Example request:
@@ -53,7 +53,7 @@ GET /projects/:id/releases/:tag_name/assets/links/:link_id
 
 | Attribute     | Type           | Required | Description                             |
 | ------------- | -------------- | -------- | --------------------------------------- |
-| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
 | `tag_name`    | string         | yes      | The tag associated with the Release. |
 | `link_id`    | integer         | yes      | The id of the link. |
 
@@ -84,7 +84,7 @@ POST /projects/:id/releases/:tag_name/assets/links
 
 | Attribute     | Type           | Required | Description                             |
 | ------------- | -------------- | -------- | --------------------------------------- |
-| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
 | `tag_name`    | string         | yes      | The tag associated with the Release. |
 | `name`        | string         | yes      | The name of the link. |
 | `url`        | string         | yes      | The URL of the link. |
@@ -120,7 +120,7 @@ PUT /projects/:id/releases/:tag_name/assets/links/:link_id
 
 | Attribute     | Type           | Required | Description                             |
 | ------------- | -------------- | -------- | --------------------------------------- |
-| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
 | `tag_name`    | string         | yes      | The tag associated with the Release. |
 | `link_id`    | integer         | yes      | The id of the link. |
 | `name`        | string         | no | The name of the link. |
@@ -156,7 +156,7 @@ DELETE /projects/:id/releases/:tag_name/assets/links/:link_id
 
 | Attribute     | Type           | Required | Description                             |
 | ------------- | -------------- | -------- | --------------------------------------- |
-| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding). |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
 | `tag_name`    | string         | yes      | The tag associated with the Release. |
 | `link_id`    | integer         | yes      | The id of the link. |
 

doc/ci/environments.md

@@ -21,7 +21,7 @@ all within GitLab. All you need to do is define them in your project's
 history of your deployments per every environment.
 
 Environments are like tags for your CI jobs, describing where code gets deployed.
-Deployments are created when [jobs] deploy versions of code to environments,
+Deployments are created when [jobs](yaml/README.md#introduction) deploy versions of code to environments,
 so every environment can have one or more deployments. GitLab keeps track of
 your deployments, so you always know what is currently being deployed on your
 servers. If you have a deployment service such as [Kubernetes][kube]
@@ -103,7 +103,7 @@ the Git SHA and environment name.
 To sum up, with the above `.gitlab-ci.yml` we have achieved that:
 
 - All branches will run the `test` and `build` jobs.
-- The `deploy_staging` job will run [only](yaml/README.md#only-and-except-simplified) on the `master`
+- The `deploy_staging` job will run [only](yaml/README.md#onlyexcept-basic) on the `master`
   branch which means all merge requests that are created from branches don't
   get to deploy to the staging server
 - When a merge request is merged, all jobs will run and the `deploy_staging`
@@ -298,8 +298,8 @@ here because it is guaranteed to be unique, but if you're using a workflow like
 environment names to be more closely based on the branch name - the example
 above would give you an URL like `https://100-do-the-thing.example.com`
 
-Last but not least, we tell the job to run [`only`][only] on branches
-[`except`][only] master.
+Last but not least, we tell the job to run [`only`](yaml/README.md#onlyexcept-basic) on branches
+[`except`](yaml/README.md#onlyexcept-basic) master.
 
 >**Note:**
 You are not bound to use the same prefix or only slashes in the dynamic
@@ -613,14 +613,12 @@ Below are some links you may find interesting:
 - [Review Apps - Use dynamic environments to deploy your code for every branch](review_apps/index.md)
 
 [Pipelines]: pipelines.md
-[jobs]: yaml/README.md#jobs
 [yaml]: yaml/README.md
 [environments]: #environments
 [deployments]: #deployments
 [permissions]: ../user/permissions.md
 [variables]: variables/README.md
 [env-name]: yaml/README.md#environmentname
-[only]: yaml/README.md#only-and-except-simplified
 [onstop]: yaml/README.md#environmenton_stop
 [ce-7015]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7015
 [gitlab-flow]: ../workflow/gitlab_flow.md

doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md

@@ -99,7 +99,7 @@ We've used the `java:8` [docker
 image](../../docker/using_docker_images.md) to build
 our application as it provides the up-to-date Java 8 JDK on [Docker
 Hub](https://hub.docker.com/). We've also added the [`only`
-clause](../../yaml/README.md#only-and-except-simplified)
+clause](../../yaml/README.md#onlyexcept-basic)
 to ensure our deployments only happen when we push to the master branch.
 
 Now, since the steps defined in `.gitlab-ci.yml` require credentials to login

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -139,7 +139,7 @@ new browser window interacting with your app as you specified.
 Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
 need to do for this:
 
-1. Set up [CI/CD jobs](../../yaml/README.md#jobs) that actually have a browser available.
+1. Set up [CI/CD jobs](../../yaml/README.md#introduction) that actually have a browser available.
 2. Update our WebdriverIO configuration to use those browsers to visit the review apps.
 
 For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
@@ -184,7 +184,7 @@ option as an argument to `npm run confidence-check` on the command line.
 However, we still need to tell WebdriverIO which browser is available for it to use.
 
 [GitLab CI/CD makes
-a number of variables available](../../variables/README.html#predefined-variables-environment-variables)
+a number of variables available](../../variables/README.html#predefined-environment-variables)
 with information about the current CI job. We can use this information to dynamically set
 up our WebdriverIO configuration according to the job that is running. More specifically, we can
 tell WebdriverIO what browser to execute the test on depending on the name of the currently running

doc/ci/variables/README.md

@@ -573,7 +573,7 @@ If any of the conditions in `variables` evaluates to truth when using `only`,
 a new job is going to be created. If any of the expressions evaluates to truth
 when `except` is being used, a job is not going to be created.
 
-This follows usual rules for [`only` / `except` policies][builds-policies].
+This follows usual rules for [`only` / `except` policies](../yaml/README.md#onlyexcept-advanced).
 
 ### Supported syntax
 
@@ -639,7 +639,6 @@ Below you can find supported syntax reference:
 [protected tags]: ../../user/project/protected_tags.md
 [shellexecutors]: https://docs.gitlab.com/runner/executors/
 [triggered]: ../triggers/README.md
-[builds-policies]: ../yaml/README.md#only-and-except-complex
 [gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
 [registry]: ../../user/project/container_registry.md
 [dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories

doc/ci/yaml/README.md

@@ -423,7 +423,7 @@ If you use multiple keys under `only` or `except`, they act as an AND. The logic
 #### `only:refs`/`except:refs`
 
 The `refs` strategy can take the same values as the
-[simplified only/except configuration](#only-and-except-simplified).
+[simplified only/except configuration](#onlyexcept-basic).
 
 In the example below, the `deploy` job is going to be created only when the
 pipeline has been [scheduled][schedules] or runs for the `master` branch:

doc/development/documentation/feature-change-workflow.md

@@ -78,7 +78,7 @@ For issues requiring any new or updated documentation, the Product Manager (PM)
 must:
 
 - Add the `Documentation` label.
-- Confirm or add the [documentation requirements](#documentation-requirements).
+- Confirm or add the [documentation requirements](#documentation-requirements-in-feature-issues).
 - Ensure the issue contains any new or updated feature name, overview/description,
   and use cases, as required per the [documentation structure and template](structure.md), when applicable.
 

doc/user/admin_area/settings/continuous_integration.md

@@ -20,7 +20,7 @@ From now on, every existing project and newly created ones that don't have a
 `.gitlab-ci.yml`, will use the Auto DevOps pipelines.
 
 If you want to disable it for a specific project, you can do so in
-[its settings](../../../topics/autodevops/index.md##enablingdisabling-auto-devops).
+[its settings](../../../topics/autodevops/index.md#enablingdisabling-auto-devops).
 
 ## Maximum artifacts size **[CORE ONLY]**
 

doc/user/discussions/index.md

@@ -11,7 +11,7 @@ You can leave a comment in the following places:
 - commit diffs
 
 There are standard comments, and you also have the option to create a comment
-in the form of a threaded discussion. A comment can also be [turned into a discussion](#start-a-discussion-by-replying-to-a-non-discussion-comment)
+in the form of a threaded discussion. A comment can also be [turned into a discussion](#start-a-discussion-by-replying-to-a-standard-comment)
 when it receives a reply.
 
 The comment area supports [Markdown] and [quick actions]. You can edit your own

doc/user/index.md

@@ -125,7 +125,7 @@ merge requests, code snippets, and commits.
 
 When performing inline reviews to implementations
 to your codebase through merge requests you can
-gather feedback through [resolvable discussions](discussions/index.md#resolvable-discussions).
+gather feedback through [resolvable discussions](discussions/index.md#resolvable-comments-and-discussions).
 
 ### GitLab Flavored Markdown (GFM)
 

doc/user/project/clusters/index.md

@@ -69,7 +69,7 @@ new Kubernetes cluster to your project:
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
    - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
      of the Virtual Machine instance that the cluster will be based on.
-   - **RBAC-enabled cluster** - Leave this checked if using default GKE creation options, see the [RBAC section](#role-based-access-control-rbac-core-only) for more information.
+   - **RBAC-enabled cluster** - Leave this checked if using default GKE creation options, see the [RBAC section](#role-based-access-control-rbac) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
 After a couple of minutes, your cluster will be ready to go. You can now proceed

doc/user/project/pages/getting_started_part_four.md

@@ -24,7 +24,7 @@ one for the first time.**
 [GitLab CI/CD](../../../ci/README.md) serves
 numerous purposes, to build, test, and deploy your app
 from GitLab through
-[Continuous Integration, Continuous Delivery, and Continuous Deployment](../../../ci/introduction/index.md#introduction-to-continuous-methods)
+[Continuous Integration, Continuous Delivery, and Continuous Deployment](../../../ci/introduction/index.md#introduction-to-cicd-methodologies)
 methods. You will need it to build your website with GitLab Pages,
 and deploy it to the Pages server.
 

doc/user/project/pages/introduction.md

@@ -152,7 +152,7 @@ Depending on how you plan to publish your website, the steps defined in the
 
 Be aware that Pages are by default branch/tag agnostic and their deployment
 relies solely on what you specify in `.gitlab-ci.yml`. If you don't limit the
-`pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except-simplified),
+`pages` job with the [`only` parameter](../../../ci/yaml/README.md#onlyexcept-basic),
 whenever a new commit is pushed to whatever branch or tag, the Pages will be
 overwritten. In the example below, we limit the Pages to be deployed whenever
 a commit is pushed only on the `master` branch:
@@ -253,7 +253,7 @@ get you started.
 
 Remember that GitLab Pages are by default branch/tag agnostic and their
 deployment relies solely on what you specify in `.gitlab-ci.yml`. You can limit
-the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#only-and-except-simplified),
+the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#onlyexcept-basic),
 whenever a new commit is pushed to a branch that will be used specifically for
 your pages.
 

doc/user/project/pipelines/schedules.md

@@ -59,7 +59,7 @@ GitLab CI so that they can be used in your `.gitlab-ci.yml` file.
 
 To configure that a job can be executed only when the pipeline has been
 scheduled (or the opposite), you can use
-[only and except](../../../ci/yaml/README.md#only-and-except-simplified) configuration keywords.
+[only and except](../../../ci/yaml/README.md#onlyexcept-basic) configuration keywords.
 
 ```
 job:on-schedule:

doc/user/snippets.md

@@ -20,7 +20,7 @@ and private. See [Public access](../public_access/public_access.md) for more inf
 ## Project snippets
 
 Project snippets are always related to a specific project.
-See [Project's features](project/index.md#projects-features) for more information.
+See [Project features](project/index.md#project-features) for more information.
 
 ## Discover snippets