Merge branch 'selhorn-environs-123' into 'master'

Edited down for style and CTRT

See merge request gitlab-org/gitlab!55432

doc/api/deployments.md

@@ -22,7 +22,7 @@ GET /projects/:id/deployments
 | `sort`           | string         | no       | Return deployments sorted in `asc` or `desc` order. Default is `asc`                                            |
 | `updated_after`  | datetime       | no       | Return deployments updated after the specified date. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`) |
 | `updated_before` | datetime       | no       | Return deployments updated before the specified date. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`) |
-| `environment`    | string         | no       | The [name of the environment](../ci/environments/index.md#defining-environments) to filter deployments by       |
+| `environment`    | string         | no       | The [name of the environment](../ci/environments/index.md) to filter deployments by       |
 | `status`         | string         | no       | The status to filter deployments by                                                                             |
 
 The status attribute can be one of the following values:
@@ -281,7 +281,7 @@ POST /projects/:id/deployments
 | Attribute     | Type           | Required | Description                                                                                                     |
 |---------------|----------------|----------|-----------------------------------------------------------------------------------------------------------------|
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `environment` | string         | yes      | The [name of the environment](../ci/environments/index.md#defining-environments) to create the deployment for   |
+| `environment` | string         | yes      | The [name of the environment](../ci/environments/index.md) to create the deployment for                         |
 | `sha`         | string         | yes      | The SHA of the commit that is deployed                                                                          |
 | `ref`         | string         | yes      | The name of the branch or tag that is deployed                                                                  |
 | `tag`         | boolean        | yes      | A boolean that indicates if the deployed ref is a tag (true) or not (false)                                     |

doc/ci/pipelines/index.md

@@ -96,7 +96,7 @@ This table lists the refspecs injected for each pipeline type:
 The refs `refs/heads/<name>` and `refs/tags/<name>` exist in your
 project repository. GitLab generates the special ref `refs/pipelines/<id>` during a
 running pipeline job. This ref can be created even after the associated branch or tag has been
-deleted. It's therefore useful in some features such as [automatically stopping an environment](../environments/index.md#automatically-stopping-an-environment),
+deleted. It's therefore useful in some features such as [automatically stopping an environment](../environments/index.md#stopping-an-environment),
 and [merge trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md)
 that might run pipelines after branch deletion.
 
@@ -208,7 +208,7 @@ You can do this straight from the pipeline graph. Just click the play button
 to execute that particular job.
 
 For example, your pipeline might start automatically, but it requires manual action to
-[deploy to production](../environments/index.md#configuring-manual-deployments). In the example below, the `production`
+[deploy to production](../environments/index.md#configure-manual-deployments). In the example below, the `production`
 stage has a job with a manual action.
 
 ![Pipelines example](img/pipelines.png)

doc/ci/review_apps/index.md

@@ -56,7 +56,7 @@ After adding Review Apps to your workflow, you follow the branched Git flow. Tha
 
 ## Configuring Review Apps
 
-Review Apps are built on [dynamic environments](../environments/index.md#configuring-dynamic-environments), which allow you to dynamically create a new environment for each branch.
+Review Apps are built on [dynamic environments](../environments/index.md#create-a-dynamic-environment), which allow you to dynamically create a new environment for each branch.
 
 The process of configuring Review Apps is as follows:
 
@@ -89,7 +89,7 @@ you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so:
 
 ## Review Apps auto-stop
 
-See how to [configure Review Apps environments to expire and auto-stop](../environments/index.md#environments-auto-stop)
+See how to [configure Review Apps environments to expire and auto-stop](../environments/index.md#stop-an-environment-after-a-certain-time-period)
 after a given period of time.
 
 ## Review Apps examples

doc/ci/yaml/README.md

@@ -2322,7 +2322,7 @@ started by a user. You might want to use manual jobs for things like deploying t
 
 To make a job manual, add `when: manual` to its configuration.
 
-Manual jobs can be started from the pipeline, job, [environment](../environments/index.md#configuring-manual-deployments),
+Manual jobs can be started from the pipeline, job, [environment](../environments/index.md#configure-manual-deployments),
 and deployment views.
 
 Manual jobs can be either optional or blocking:
@@ -2562,7 +2562,7 @@ it is set to `manual`, so it needs a [manual action](#whenmanual) from
 the GitLab UI to run.
 
 Also in the example, `GIT_STRATEGY` is set to `none`. If the
-`stop_review_app` job is [automatically triggered](../environments/index.md#automatically-stopping-an-environment),
+`stop_review_app` job is [automatically triggered](../environments/index.md#stopping-an-environment),
 the runner won’t try to check out the code after the branch is deleted.
 
 The example also overwrites global variables. If your `stop` `environment` job depends
@@ -2608,7 +2608,7 @@ When the environment for `review_app` is created, the environment's lifetime is
 Every time the review app is deployed, that lifetime is also reset to `1 day`.
 
 For more information, see
-[the environments auto-stop documentation](../environments/index.md#environments-auto-stop)
+[the environments auto-stop documentation](../environments/index.md#stop-an-environment-after-a-certain-time-period)
 
 #### `environment:kubernetes`
 
@@ -2634,7 +2634,7 @@ environment, using the `production`
 [Kubernetes namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
 
 For more information, see
-[Available settings for `kubernetes`](../environments/index.md#configuring-kubernetes-deployments).
+[Available settings for `kubernetes`](../environments/index.md#configure-kubernetes-deployments).
 
 NOTE:
 Kubernetes configuration is not supported for Kubernetes clusters

doc/development/testing_guide/review_apps.md

@@ -109,7 +109,7 @@ subgraph "CNG-mirror pipeline"
 ### Auto-stopping of Review Apps
 
 Review Apps are automatically stopped 2 days after the last deployment thanks to
-the [Environment auto-stop](../../ci/environments/index.md#environments-auto-stop) feature.
+the [Environment auto-stop](../../ci/environments/index.md#stop-an-environment-after-a-certain-time-period) feature.
 
 If you need your Review App to stay up for a longer time, you can
 [pin its environment](../../ci/environments/index.md#auto-stop-example) or retry the

doc/topics/autodevops/customize.md

@@ -204,7 +204,7 @@ into your project and edit it as needed.
 
 For clusters not managed by GitLab, you can customize the namespace in
 `.gitlab-ci.yml` by specifying
-[`environment:kubernetes:namespace`](../../ci/environments/index.md#configuring-kubernetes-deployments).
+[`environment:kubernetes:namespace`](../../ci/environments/index.md#configure-kubernetes-deployments).
 For example, the following configuration overrides the namespace used for
 `production` deployments:
 

doc/user/project/clusters/index.md

@@ -312,7 +312,7 @@ following command in your deployment job script, for Kubernetes to access the re
 The Kubernetes cluster integration exposes these
 [deployment variables](../../../ci/variables/README.md#deployment-variables) in the
 GitLab CI/CD build environment to deployment jobs. Deployment jobs have
-[defined a target environment](../../../ci/environments/index.md#defining-environments).
+[defined a target environment](../../../ci/environments/index.md).
 
 | Deployment Variable        | Description |
 |----------------------------|-------------|
@@ -345,7 +345,7 @@ You can customize the deployment namespace in a few ways:
 - For **non-managed** clusters, the auto-generated namespace is set in the `KUBECONFIG`,
   but the user is responsible for ensuring its existence. You can fully customize
   this value using
-  [`environment:kubernetes:namespace`](../../../ci/environments/index.md#configuring-kubernetes-deployments)
+  [`environment:kubernetes:namespace`](../../../ci/environments/index.md#configure-kubernetes-deployments)
   in `.gitlab-ci.yml`.
 
 When you customize the namespace, existing environments remain linked to their current
@@ -432,7 +432,7 @@ Reasons for failure include:
 - The token you gave GitLab does not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
   privileges required by GitLab.
 - Missing `KUBECONFIG` or `KUBE_TOKEN` deployment variables. To be passed to your job, they must have a matching
-  [`environment:name`](../../../ci/environments/index.md#defining-environments). If your job has no
+  [`environment:name`](../../../ci/environments/index.md). If your job has no
   `environment:name` set, the Kubernetes credentials are not passed to it.
 
 NOTE:

doc/user/project/deploy_boards.md

@@ -75,7 +75,7 @@ specific environment, there are a lot of use cases. To name a few:
 
 To display the Deploy Boards for a specific [environment](../../ci/environments/index.md) you should:
 
-1. Have [defined an environment](../../ci/environments/index.md#defining-environments) with a deploy stage.
+1. Have [defined an environment](../../ci/environments/index.md) with a deploy stage.
 
 1. Have a Kubernetes cluster up and running.