Revise metadata for consistency

Revise metadata for consistency

data/removals/14_0/remove_optimize_api.yml

-- name: "Segments removed from DevOps Adoption API "
+- name: "Segments removed from DevOps Adoption API"
   removal_date: "2021-06-22"
   removal_milestone: "14.0"
   reporter: ljlane

doc/administration/logs.md

@@ -21,7 +21,7 @@ switching logs from JSON to plain text logging, and more.
 - [How to parse and analyze JSON logs](troubleshooting/log_parsing.md).
 
 ## Log Levels
- 
+
 Each log message has an assigned log level that indicates its importance and verbosity.
 Each logger has an assigned minimum log level.
 A logger emits a log message only if its log level is equal to or above the minimum log level.

doc/administration/package_information/defaults.md

 ---
 stage: Enablement
 group: Distribution
-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/#designated-technical-writers
+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
 ---
 
 # Package defaults **(FREE SELF)**
@@ -71,5 +71,5 @@ NOTE:
 In some cases, the GitLab Registry will be automatically enabled by default. Please see [our documentation](../packages/container_registry.md) for more details
 
  [^Consul-notes]: If using additional Consul functionality, more ports may need to be opened. See the [official documentation](https://www.consul.io/docs/install/ports#ports-table) for the list.
- 
+
  [^Sidekiq-health]: If Sidekiq health check settings are not set, they will default to the Sidekiq metrics exporter settings. This default is deprecated and is set to be removed in [GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/347509).

doc/administration/sidekiq.md

@@ -2,7 +2,6 @@
 stage: Enablement
 group: Distribution
 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: reference
 ---
 
 # Configuring Sidekiq **(FREE SELF)**
@@ -152,7 +151,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
 
    NOTE:
    If health check settings are not set, they will default to the metrics exporter settings.
-   This default is deprecated and is set to be removed in [GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/347509). 
+   This default is deprecated and is set to be removed in [GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/347509).
 
 1. Run `gitlab-ctl reconfigure`.
 

doc/administration/sidekiq_health_check.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Sidekiq Health Check **(FREE SELF)**
 
 GitLab provides liveness and readiness probes to indicate service health and
-reachability to the Sidekiq cluster. These endpoints 
+reachability to the Sidekiq cluster. These endpoints
 [can be provided to schedulers like Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
 to hold traffic until the system is ready or restart the container as needed.
 

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -2,7 +2,6 @@
 stage: Enablement
 group: Distribution
 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: reference
 ---
 
 # GitLab Rails Console Cheat Sheet **(FREE SELF)**
@@ -1282,8 +1281,8 @@ Gitlab::GitalyClient::ServerService.new("default").storage_disk_statistics
 
 ## Generate Service Ping
 
-The [Service Ping Guide](../../development/service_ping/index.md) in our developer documentation 
-has more information about Service Ping. 
+The [Service Ping Guide](../../development/service_ping/index.md) in our developer documentation
+has more information about Service Ping.
 
 ### Generate or get the cached Service Ping
 
@@ -1309,7 +1308,7 @@ rake gitlab:usage_data:generate
 
 Generates Service Ping data in YAML format:
 
-```shell 
+```shell
 rake gitlab:usage_data:dump_sql_in_yaml
 ```
 

doc/api/members.md

@@ -88,7 +88,7 @@ Example response:
 ]
 ```
 
-## List all members of a group or project including inherited and invited members 
+## List all members of a group or project including inherited and invited members
 
 Gets a list of group or project members viewable by the authenticated user, including inherited members, invited users, and permissions through ancestor groups.
 

doc/ci/cloud_services/aws/index.md

@@ -21,8 +21,8 @@ Create GitLab as a IAM OIDC provider in AWS following these [instructions](https
 
 Include the following information:
 
-- **Provider URL**: The address of your GitLab instance, such as `https://gitlab.com` or `http://gitlab.example.com`. 
-- **Audience**: The address of your GitLab instance, such as `https://gitlab.com` or `http://gitlab.example.com`. 
+- **Provider URL**: The address of your GitLab instance, such as `https://gitlab.com` or `http://gitlab.example.com`.
+- **Audience**: The address of your GitLab instance, such as `https://gitlab.com` or `http://gitlab.example.com`.
   - The address must include `https://`.
   - Do not include a trailing slash.
 
@@ -56,7 +56,7 @@ After the role is created, attach a policy defining permissions to an AWS servic
 
 ## Retrieve temporary credentials
 
-After you configure the OIDC and role, the GitLab CI/CD job can retrieve a temporary credential from [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html). 
+After you configure the OIDC and role, the GitLab CI/CD job can retrieve a temporary credential from [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html).
 
 ```yaml
 assume role:
@@ -78,7 +78,7 @@ assume role:
 - `CI_JOB_JWT_V2`: Predefined variable.
 - `ROLE_ARN`: The role ARN defined in this [step](#configure-a-role-and-trust).
 
-## Working example 
+## Working example
 
 See this [reference project](https://gitlab.com/guided-explorations/aws/configure-openid-connect-in-aws) for provisioning OIDC in AWS using Terraform and a sample script to retrieve temporary credentials.
 

doc/ci/cloud_services/index.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Connect to cloud services
 
 > - `CI_JOB_JWT` variable for reading secrets from Vault [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207125) in GitLab 12.10.
-> - `CI_JOB_JWT_V2` variable to support additional OIDC providers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346737) in GitLab 14.7. 
+> - `CI_JOB_JWT_V2` variable to support additional OIDC providers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346737) in GitLab 14.7.
 
 GitLab CI/CD supports [OpenID Connect (OIDC)](https://openid.net/connect/faq/) that allows your build and deployment job access to cloud credentials and services. Historically, teams stored secrets in projects or applied permissions on the GitLab Runner instance to build and deploy. To support this, a predefined variable named `CI_JOB_JWT_V2` is included in the CI/CD job allowing you to follow a scalable and least-privilege security approach.
 
@@ -19,7 +19,7 @@ GitLab CI/CD supports [OpenID Connect (OIDC)](https://openid.net/connect/faq/) t
 The original implementation of `CI_JOB_JWT` supports [HashiCorp Vault integration](../examples/authenticating-with-hashicorp-vault/). The updated implementation of `CI_JOB_JWT_V2` supports additional cloud providers with OIDC including AWS, GCP, and Vault.
 
 WARNING:
-The `CI_JOB_JWT_V2` variable is under development [(alpha)](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha) and is not yet suitable for production use. 
+The `CI_JOB_JWT_V2` variable is under development [(alpha)](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha) and is not yet suitable for production use.
 
 ## Use cases
 
@@ -29,7 +29,7 @@ The `CI_JOB_JWT_V2` variable is under development [(alpha)](https://about.gitlab
 - Allows shared runners to securely access multiple cloud accounts. The access is determined by the JWT token, which is specific to the user running the pipeline.
 - Removes the need to create logic to rotate secrets by retrieving temporary credentials by default.
 
-## How it works 
+## How it works
 
 Each job has a JSON web token (JWT) provided as a CI/CD [predefined variable](../variables/predefined_variables.md) named `CI_JOB_JWT` or `CI_JOB_JWT_V2`. This JWT can be used to authenticate with the OIDC-supported cloud provider such as AWS, GCP, or Vault.
 
@@ -87,7 +87,7 @@ The following fields are included in the JWT:
 }
 ```
 
-### Authorization workflow 
+### Authorization workflow
 
 ```mermaid
 sequenceDiagram
@@ -107,8 +107,8 @@ sequenceDiagram
 
 1. Create an OIDC identity provider in the cloud (for example, AWS, GCP, Vault).
 1. Create a conditional role in the cloud service that filters to a group, project, branch, or tag.
-1. The CI/CD job includes a predefined variable `CI_JOB_JWT_V2` that is a JWT token. You can use this token for authorization with your cloud API. 
-1. The cloud verifies the token, validates the conditional role from the payload, and returns a temporary credential. 
+1. The CI/CD job includes a predefined variable `CI_JOB_JWT_V2` that is a JWT token. You can use this token for authorization with your cloud API.
+1. The cloud verifies the token, validates the conditional role from the payload, and returns a temporary credential.
 
 ## Configure a conditional role with OIDC claims
 
@@ -116,7 +116,7 @@ To configure the trust between GitLab and OIDC, you must create a conditional ro
 
 - Audience or `aud`: The URL of the GitLab instance. This is defined when the identity provider is first configured in your cloud provider.
 - Subject or `sub`: A concatenation of metadata describing the GitLab CI/CD workflow including the group, project, branch, and tag. The `sub` field is in the following format:
-  - `project_path:{group}/{project}:ref_type:{type}:ref:{branch_name}` 
+  - `project_path:{group}/{project}:ref_type:{type}:ref:{branch_name}`
 
 | Filter type                          | Example                                                      |
 | ------------------------------------ | ------------------------------------------------------------ |

doc/ci/runners/configure_runners.md

@@ -2,7 +2,6 @@
 stage: Verify
 group: Runner
 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: reference
 ---
 
 # Configuring runners **(FREE)**
@@ -640,7 +639,7 @@ support this feature.
 
 A meter can be enabled to provide the rate of transfer for uploads and downloads.
 
-You can set a maximum time for cache upload and download with the `CACHE_REQUEST_TIMEOUT` setting. 
+You can set a maximum time for cache upload and download with the `CACHE_REQUEST_TIMEOUT` setting.
 This setting can be useful when slow cache uploads substantially increase the duration of your job.
 
 ```yaml

doc/development/database_review.md

@@ -140,7 +140,7 @@ of error that would result in corruption or loss of production data.
 Include in the MR description:
 
 - If the migration itself is not reversible, details of how data changes could be reverted in the event of an incident. For example, in the case of a migration that deletes records (an operation that most of the times is not automatically revertable), how _could_ the deleted records be recovered.
-- If the migration deletes data apply the label `~data-deletion` 
+- If the migration deletes data, apply the label `~data-deletion`.
 - Concise descriptions of possible user experience impact of an error; for example, "Issues would unexpectedly go missing from Epics".
 - Relevant data from the [query plans](#query-plans) that indicate the query works as expected; such as the approximate number of records that will be modified/deleted.
 

doc/development/event_store.md

@@ -285,7 +285,7 @@ This technique can avoid scheduling Sidekiq jobs if the subscriber is interested
 small subset of events.
 
 WARNING:
-When using conditional dispatch it must contain only cheap conditions because they are 
+When using conditional dispatch it must contain only cheap conditions because they are
 executed synchronously every time the given event is published.
 
 For complex conditions it's best to subscribe to all the events and then handle the logic

doc/development/integrations/secure.md

@@ -331,7 +331,7 @@ You can find the schemas for these scanners here:
 
 In GitLab 14.10 and later, report validation against the schemas is enabled. To enable report validation for versions earlier than 14.10,
 set [`VALIDATE_SCHEMA`](../../user/application_security/#enable-security-report-validation) to
-`"true"`. 
+`"true"`.
 
 Reports that don't pass validation are not ingested by GitLab, and an error message
 displays on the corresponding pipeline.

doc/install/aws/index.md

@@ -63,7 +63,7 @@ When deploying a GitLab instance using the official AMI, the root password to th
 Instances running on Community Edition (CE) require a migration to Enterprise Edition (EE) in order to subscribe to the GitLab Premium or Ultimate plan. If you want to pursue a subscription, using the Free-forever plan of Enterprise Edition is the least disruptive method.
 
 NOTE:
-Since any given GitLab upgrade might involve data disk updates or database schema upgrades, simply swapping out the AMI is not sufficent for taking upgrades. 
+Since any given GitLab upgrade might involve data disk updates or database schema upgrades, simply swapping out the AMI is not sufficent for taking upgrades.
 
 1. Log in to the AWS Web Console, so that clicking the links in the following step take you directly to the AMI list.
 1. Pick the edition you want:

doc/security/reset_user_password.md

@@ -68,12 +68,12 @@ If you know the username, user ID, or email address, you can use the Rails conso
      user = User.find(123)
      ```
 
-   - By email address: 
+   - By email address:
 
      ```ruby
      user = User.find_by(email: 'user@example.com')
      ```
-      
+
 1. Reset the password:
 
    ```ruby
@@ -105,7 +105,7 @@ To reset the root password, follow the steps listed previously.
 
 - If the root account name hasn't changed, use the username `root`.
 - If the root account name has changed and you don't know the new username,
-  you might be able to use a Rails console with user ID `1`. In almost all 
+  you might be able to use a Rails console with user ID `1`. In almost all
   cases, the first user is the default administrator account.
 
 ## Troubleshooting

doc/system_hooks/system_hooks.md

@@ -45,7 +45,7 @@ System hooks can be used, for example, for logging or changing information in an
 LDAP server.
 
 In addition to these default events, you can enable triggers for other events,
-such as push events, and disable the `repository_update` event 
+such as push events, and disable the `repository_update` event
 when you create a system hook.
 
 NOTE:

doc/update/removals.md

@@ -292,7 +292,7 @@ To better support the latest versions of Ruby, the template is changed to use `r
 
 Relevant Issue: [Updates Ruby version 2.5 to 3.0](https://gitlab.com/gitlab-org/gitlab/-/issues/329160)
 
-### Segments removed from DevOps Adoption API 
+### Segments removed from DevOps Adoption API
 
 The first release of the DevOps Adoption report had a concept of **Segments**. Segments were [quickly removed from the report](https://gitlab.com/groups/gitlab-org/-/epics/5251) because they introduced an additional layer of complexity on top of **Groups** and **Projects**. Subsequent iterations of the DevOps Adoption report focus on comparing adoption across groups rather than segments. GitLab 14.0 removes all references to **Segments** [from the GraphQL API](https://gitlab.com/gitlab-org/gitlab/-/issues/324414) and replaces them with **Enabled groups**.
 

doc/user/admin_area/analytics/dev_ops_report.md

@@ -59,7 +59,7 @@ You can use Group DevOps Adoption to:
 
 - Identify specific subgroups that are lagging in their adoption of GitLab features, so you can guide them on
 their DevOps journey.
-- Find subgroups that have adopted certain features, and provide guidance to other subgroups on 
+- Find subgroups that have adopted certain features, and provide guidance to other subgroups on
 how to use those features.
 - Verify if you are getting the return on investment that you expected from GitLab.
 

doc/user/admin_area/settings/third_party_offers.md

@@ -13,7 +13,7 @@ Within GitLab, we inform users of available third-party offers they might find v
 to enhance the development of their projects. An example is the Google Cloud Platform free credit
 for using [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/).
 
-Furthermore, we use content to improve customer experience. An example are the personalization 
+Furthermore, we use content to improve customer experience. An example are the personalization
 questions when creating a group.
 
 To toggle the display of customer experience improvement content and third-party offers:

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -190,7 +190,7 @@ To restrict visibility levels for projects, snippets, and selected pages:
 1. In the **Restricted visibility levels** section, select the desired visibility levels to restrict.
    If you restrict the **Public** level:
    - User profiles are only visible to logged in users via the Web interface.
-   - User attributes are only visible to authenticated users via the GraphQL API. 
+   - User attributes are only visible to authenticated users via the GraphQL API.
 1. Select **Save changes**.
 
 For more details on project visibility, see

doc/user/application_security/sast/index.md

@@ -310,9 +310,9 @@ To disable analyzer rules:
 
 1. Set the `disabled` flag to `true` in the context of a `ruleset` section
 
-1. In one or more `ruleset.identifier` sub sections, list the rules that you want disabled. Every `ruleset.identifier` section has: 
+1. In one or more `ruleset.identifier` sub sections, list the rules that you want disabled. Every `ruleset.identifier` section has:
 
-- a `type` field, to name the predefined rule identifier that the targeted analyzer uses. 
+- a `type` field, to name the predefined rule identifier that the targeted analyzer uses.
 
 - a `value` field, to name the rule to be disabled.
 
@@ -345,7 +345,7 @@ and `sobelow` by matching the `type` and `value` of identifiers:
 
 #### Synthesize a custom configuration
 
-To create a custom configuration, you can use passthrough chains. 
+To create a custom configuration, you can use passthrough chains.
 
 A passthrough is a single step in a passthrough chain. The passthrough is evaluated
 in a sequence to incrementally build a configuration. The configuration is then
@@ -359,8 +359,8 @@ parameters:
 | `description` | Description about the analyzer configuration section. |
 | `targetdir`   | The `targetdir` parameter defines the directory where the final configuration is located. If `targetdir` is empty, the analyzer uses a random directory. The maximum size of `targetdir` is 100MB. |
 | `validate`    | If set to `true`, the target files for passthroughs (`raw`, `file` and `url`) are validated. The validation works for `yaml`, `xml`, `json` and `toml` files. The proper validator is identified based on the extension of the target file. By default, `validate` is set to `false`. |
-| `interpolate` | If set to `true`, environment variable interpolation is enabled so that the configuration uses secrets/tokens. We advise using this feature with caution to not leak any secrets. By default, `interpolate` is set to `false`. | 
-| `timeout`     | The total `timeout` for the evaluation of a passthrough chain is set to 60 seconds. If `timeout` is not set, the default timeout is 60 seconds. The timeout cannot exceed 300 seconds. | 
+| `interpolate` | If set to `true`, environment variable interpolation is enabled so that the configuration uses secrets/tokens. We advise using this feature with caution to not leak any secrets. By default, `interpolate` is set to `false`. |
+| `timeout`     | The total `timeout` for the evaluation of a passthrough chain is set to 60 seconds. If `timeout` is not set, the default timeout is 60 seconds. The timeout cannot exceed 300 seconds. |
 
 A configuration section can include one or more passthrough sections. The maximum number of passthrough sections is 20.
 There are several types of passthroughs:
@@ -373,12 +373,12 @@ There are several types of passthroughs:
 | `url`  | Fetch the analyzer configuration through HTTP. |
 
 If multiple passthrough sections are defined in a passthrough chain, their
-position in the chain defines the order in which they are evaluated. 
+position in the chain defines the order in which they are evaluated.
 
-- Passthroughs listed later in the chain sequence have a higher precedence. 
+- Passthroughs listed later in the chain sequence have a higher precedence.
 - Passthroughs with a higher precedence overwrite (default) and append data
   yielded by previous passthroughs. This is useful for cases where you need to
-  use or modify an existing configuration. 
+  use or modify an existing configuration.
 
 Configure a passthrough these parameters:
 
@@ -453,7 +453,7 @@ file `gosec-config.json`:
 ##### Passthrough chain for semgrep
 
 In the below example, we generate a custom configuration under the `/sgrules`
-target directory with a total `timeout` of 60 seconds. 
+target directory with a total `timeout` of 60 seconds.
 
 Several passthrouh types generate a configuration for the target analyzer:
 
@@ -462,17 +462,17 @@ Several passthrouh types generate a configuration for the target analyzer:
   `97f7686` from the `sast-rules` Git repostory. From the `sast-rules` Git
   repository, only data from the `go` subdirectory is considered.
   - The `sast-rules` entry has a higher precedence because it appears later in
-    the configuration. 
+    the configuration.
   - If there is a filename collision between files in both repositories, files
     from the `sast` repository overwrite files from the `myrules` repository,
     as `sast-rules` has higher precedence.  
 - The `raw` entry creates a file named `insecure.yml` under `/sgrules`. The
-  full path is `/sgrules/insecure.yml`. 
+  full path is `/sgrules/insecure.yml`.
 - The `url` entry fetches a configuration made available through a URL and
-  stores it in the `/sgrules/gosec.yml` file. 
+  stores it in the `/sgrules/gosec.yml` file.
 
 Afterwards, semgrep is invoked with the final configuration located under
-`/sgrules`. 
+`/sgrules`.
 
 ```toml
 [semgrep]
@@ -536,17 +536,17 @@ It does not explicitly store credentials in the configuration file. To reduce th
 ##### Configure the append mode for passthroughs
 
 To append data to previous passthroughs, use the `append` mode for the
-passthrough types `file`, `url`, and `raw`. 
+passthrough types `file`, `url`, and `raw`.
 
 Passthroughs in `override` mode overwrite files
 created when preceding passthroughs in the chain find a naming
 collision. If `mode` is set to `append`, a passthrough appends data to the
-files created by its predecessors instead of overwriting. 
+files created by its predecessors instead of overwriting.
 
 In the below semgrep configuration,`/sgrules/insecure.yml` assembles two passthroughs. The rules are:
 
 - `insecure`
-- `secret` 
+- `secret`
 
 These rules add a search pattern to the analyzer and extends semgrep capabilities.
 

doc/user/application_security/security_dashboard/index.md

@@ -128,7 +128,7 @@ To view vulnerabilities over time for a group:
 1. Select **Security > Security Dashboard**.
 1. Hover over the chart to get more details about vulnerabilities.
    - You can display the vulnerability trends over a 30, 60, or 90-day time frame (the default is 90 days).
-   - To view aggregated data beyond a 90-day time frame, use the 
+   - To view aggregated data beyond a 90-day time frame, use the
      [VulnerabilitiesCountByDay GraphQL API](../../../api/graphql/reference/index.md#vulnerabilitiescountbyday).
      GitLab retains the data for 365 days.
 

doc/user/clusters/agent/index.md

@@ -142,8 +142,8 @@ To remove an agent from the UI:
 
 1. Go to your agent's configuration repository.
 1. From your project's sidebar, select **Infrastructure > Kubernetes clusters**.
-1. Select your agent from the table, and then in the **Options** column, click the vertical ellipsis 
-(**{ellipsis_v}**) button and select **Delete agent**. 
+1. Select your agent from the table, and then in the **Options** column, click the vertical ellipsis
+(**{ellipsis_v}**) button and select **Delete agent**.
 
 ### Remove an agent with the GitLab GraphQL API
 

doc/user/infrastructure/iac/index.md

@@ -41,10 +41,10 @@ This template includes the following parameters that you can override:
   `test`, `validate`, `build`, and `deploy`. These stages
   [run the Terraform commands](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform/Base.latest.gitlab-ci.yml)
   `test`, `validate`, `plan`, `plan-json`, and `apply`. The `apply` command only runs on the default branch.
-- Runs the [Terraform SAST scanner](../../application_security/iac_scanning/index.md#configure-iac-scanning-manually), 
+- Runs the [Terraform SAST scanner](../../application_security/iac_scanning/index.md#configure-iac-scanning-manually),
   that you can disable by creating a `SAST_DISABLED` environment variable and setting it to `1`.
 
-The latest template described above might contain breaking changes between major GitLab releases. For users requiring more stable setups, we 
+The latest template described above might contain breaking changes between major GitLab releases. For users requiring more stable setups, we
 recommend using the stable templates:
 
 - [A ready to use version](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml)

doc/user/packages/dependency_proxy/index.md

@@ -231,7 +231,7 @@ You can enable an automatic time-to-live (TTL) policy for the Dependency Proxy f
 interface. To do this, navigate to your group's **Settings > Packages & Registries > Dependency Proxy**
 and enable the setting to automatically clear items from the cache after 90 days.
 
-#### Enable cleanup policies with GraphQL 
+#### Enable cleanup policies with GraphQL
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294187) in GitLab 14.4.
 
@@ -263,7 +263,7 @@ mutation {
 ```
 
 See the [Getting started with GraphQL](../../../api/graphql/getting_started.md)
-guide to learn how to make GraphQL queries. 
+guide to learn how to make GraphQL queries.
 
 When the policy is initially enabled, the default TTL setting is 90 days. Once enabled, stale
 dependency proxy files are queued for deletion each day. Deletion may not occur right away due to

doc/user/project/code_owners.md

@@ -289,12 +289,12 @@ A Code Owner approval rule is optional if these conditions are not met:
 
 ### Approvals do not show
 
-Code Owner approval rules only update when the merge request is created. 
+Code Owner approval rules only update when the merge request is created.
 If you update the `CODEOWNERS` file, close the merge request and create a new one.
 
 ### User not shown as possible approver
 
-A user might not show as an approver on the Code Owner merge request approval rules. 
+A user might not show as an approver on the Code Owner merge request approval rules.
 
 This result occurs when a rule prevents the specific user from approving the merge request.
 Check the project

doc/user/project/integrations/discord_notifications.md

@@ -16,7 +16,7 @@ and configure it in GitLab.
 1. Open the Discord channel you want to receive GitLab event notifications.
 1. From the channel menu, select **Edit channel**.
 1. Select **Integrations**.
-1. If there are no existing webhooks, select **Create Webhook**. Otherwise, select **View Webhooks** then **New Webhook**. 
+1. If there are no existing webhooks, select **Create Webhook**. Otherwise, select **View Webhooks** then **New Webhook**.
 1. Enter the name of the bot to post the message.
 1. Optional. Edit the avatar.
 1. Copy the URL from the **WEBHOOK URL** field.

doc/user/project/merge_requests/accessibility_testing.md

@@ -73,5 +73,5 @@ link to the [current template in the default branch](https://gitlab.com/gitlab-o
 NOTE:
 The job definition provided by the template does not support Kubernetes.
 
-You cannot pass configurations into Pa11y via CI configuration. 
+You cannot pass configurations into Pa11y via CI configuration.
 To change the configuration, edit a copy of the template in your CI file.

doc/user/project/merge_requests/commit_templates.md

@@ -88,7 +88,7 @@ Commit message templates support these variables:
 | `%{co_authored_by}` | Names and emails of commit authors in a `Co-authored-by` Git commit trailer format. Limited to authors of 100 most recent commits in merge request. | `Co-authored-by: Zane Doe <zdoe@example.com>` <br> `Co-authored-by: Blake Smith <bsmith@example.com>` |
 
 Any line containing only an empty variable is removed. If the line to be removed is both
-preceded and followed by an empty line, the preceding empty line is also removed. 
+preceded and followed by an empty line, the preceding empty line is also removed.
 
 ## Related topics
 

doc/user/project/working_with_projects.md

@@ -16,7 +16,7 @@ To explore projects:
 1. On the top bar, select **Menu > Projects**.
 1. Select **Explore projects**.
 
-The **Projects** page shows a list of projects, sorted by last updated date. 
+The **Projects** page shows a list of projects, sorted by last updated date.
 
 - To view projects with the most [stars](#star-a-project), select **Most stars**.
 - To view projects with the largest number of comments in the past month, select **Trending**.
@@ -326,7 +326,7 @@ on the project dashboard when a project is part of a group under a
 Prerequisites:
 
 - Contact your administrator to enable the [GitLab Go Proxy](../packages/go_proxy/index.md).
-- To use a private project in a subgroup as a Go package, you must [authenticate Go requests](#authenticate-go-requests-to-private-projects). Go requests that are not authenticated cause 
+- To use a private project in a subgroup as a Go package, you must [authenticate Go requests](#authenticate-go-requests-to-private-projects). Go requests that are not authenticated cause
 `go get` to fail. You don't need to authenticate Go requests for projects that are not in subgroups.
 
 To use a project as a Go package, use the `go get` and `godoc.org` discovery requests. You can use the meta tags:

doc/user/search/index.md

@@ -141,7 +141,7 @@ you can choose from:
 
 ![Filter MRs by their environment](img/filtering_merge_requests_by_environment_v14_6.png)
 
-When filtering by `Deployed-before` or `Deployed-after`, the date refers to when 
+When filtering by `Deployed-before` or `Deployed-after`, the date refers to when
 the deployment to an environment (triggered by the merge commit) completed successfully.
 You must enter the deploy date manually. Deploy dates
 use the format `YYYY-MM-DD`, and must be quoted if you wish to specify