Merge branch 'docs-aqualls-spelling-catchup' into 'master'

Catch up on spelling issues that have crept in

See merge request gitlab-org/gitlab!62013

doc/.vale/gitlab/spelling-exceptions.txt

@@ -563,6 +563,7 @@ smartcard
 smartcards
 snapshotting
 Sobelow
+Solargraph
 Solarized
 Sourcegraph
 sparkline

doc/ci/cloud_deployment/ecs/quick_start_guide.md

@@ -232,7 +232,7 @@ These variables are injected into the pipeline jobs and can access the ECS API.
 Change a file in the project and see if it's reflected in the demo application on ECS:
 
 1. Go to **ecs-demo** project on GitLab.
-1. Open the file at **app > views > welcome > index.html.erb**.
+1. Open the file at **app > views > welcome > `index.html.erb`**.
 1. Click **Edit**.
 1. Change the text to `You're on ECS!`.
 1. Click **Commit Changes**. This automatically triggers a new pipeline. Wait until it finishes.

doc/development/agent/local.md

@@ -116,7 +116,7 @@ Before performing any of these tests, if you have a `k3s` instance running, make
 stop it manually before running them. Otherwise, the tests might fail with the message
 `failed to remove k3s cluster`.
 
-You might need to specify the correct Agent image version that matches the `kas` image version. You can use the `GITLAB_AGENTK_VERSION` local env for this.
+You might need to specify the correct Agent image version that matches the `kas` image version. You can use the `GITLAB_AGENTK_VERSION` local environment for this.
 
 ### Against `staging`
 
@@ -124,7 +124,7 @@ You might need to specify the correct Agent image version that matches the `kas`
    [this line](https://gitlab.com/gitlab-org/gitlab/-/blob/5b15540ea78298a106150c3a1d6ed26416109b9d/qa/qa/service/cluster_provider/k3s.rb#L8) and
    [this line](https://gitlab.com/gitlab-org/gitlab/-/blob/5b15540ea78298a106150c3a1d6ed26416109b9d/qa/qa/service/cluster_provider/k3s.rb#L36).
    We don't allow local connections on `staging` as they require an admin user.
-1. Ensure you don't have an `EE_LICENSE` env var set as this would force an admin login.
+1. Ensure you don't have an `EE_LICENSE` environment variable set as this would force an admin login.
 1. Go to your GDK root folder and `cd gitlab/qa`.
 1. Login with your user in staging and create a group to be used as sandbox.
    Something like: `username-qa-sandbox`.

doc/development/contributing/style_guides.md

@@ -101,7 +101,7 @@ You can check for any offenses locally with `bundle exec rubocop --parallel`.
 On the CI, this is automatically checked by the `static-analysis` jobs.
 
 In addition, you can [integrate RuboCop](../developing_with_solargraph.md) into
-supported IDEs using the [solargraph](https://github.com/castwide/solargraph) gem.
+supported IDEs using the [Solargraph](https://github.com/castwide/solargraph) gem.
 
 For RuboCop rules that we have not taken a decision on yet, we follow the
 [Ruby Style Guide](https://github.com/rubocop-hq/ruby-style-guide),

doc/development/developing_with_solargraph.md

@@ -8,21 +8,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Gemfile packages [Solargraph](https://github.com/castwide/solargraph) language server for additional IntelliSense and code formatting capabilities with editors that support it.
 
-Example configuration for solargraph can be found in [.solargraph.yml.example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.solargraph.yml.example) file. Copy the contents of this file to `.solargraph.yml` file for language server to pick this configuration up. Since `.solargraph.yml` configuration file is ignored by Git, it's possible to adjust configuration according to your needs.
+Example configuration for Solargraph can be found in [.solargraph.yml.example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.solargraph.yml.example) file. Copy the contents of this file to `.solargraph.yml` file for language server to pick this configuration up. Since `.solargraph.yml` configuration file is ignored by Git, it's possible to adjust configuration according to your needs.
 
-Refer to particular IDE plugin documentation on how to integrate it with solargraph language server:
+Refer to particular IDE plugin documentation on how to integrate it with Solargraph language server:
 
 - **Visual Studio Code**
-  - GitHub: [vscode-solargraph](https://github.com/castwide/vscode-solargraph)
+  - GitHub: [`vscode-solargraph`](https://github.com/castwide/vscode-solargraph)
 
 - **Atom**
-  - GitHub: [atom-solargraph](https://github.com/castwide/atom-solargraph)
+  - GitHub: [`atom-solargraph`](https://github.com/castwide/atom-solargraph)
 
 - **Vim**
-  - GitHub: [LanguageClient-neovim](https://github.com/autozimu/LanguageClient-neovim)
+  - GitHub: [`LanguageClient-neovim`](https://github.com/autozimu/LanguageClient-neovim)
 
 - **Emacs**
-  - GitHub: [emacs-solargraph](https://github.com/guskovd/emacs-solargraph)
+  - GitHub: [`emacs-solargraph`](https://github.com/guskovd/emacs-solargraph)
 
 - **Eclipse**
-  - GitHub: [eclipse-solargraph](https://github.com/PyvesB/eclipse-solargraph)
+  - GitHub: [`eclipse-solargraph`](https://github.com/PyvesB/eclipse-solargraph)

doc/development/experiment_guide/index.md

@@ -59,4 +59,4 @@ feature flags, and there is currently no strong suggestion to use one over the o
 
 Historical Context: `Experimentation Module` was built iteratively with the needs that
 appeared while implementing Growth sub-department experiments, while GLEX was built
-with the learnings of the team and an easier to use API.
+with the findings of the team and an easier to use API.

doc/development/fe_guide/graphql.md

@@ -782,7 +782,7 @@ While the Apollo client has support for simple polling, for performance reasons,
 
 Once the backend is set up, there are a few changes to make on the frontend.
 
-First, get your resource Etag path from the backend. In the example of the pipelines graph, this is called the `graphql_resource_etag`. This will be used to create new headers to add to the Apollo context:
+First, get your resource ETag path from the backend. In the example of the pipelines graph, this is called the `graphql_resource_etag`. This will be used to create new headers to add to the Apollo context:
 
 ```javascript
 /* pipelines/components/graph/utils.js */
@@ -817,7 +817,7 @@ apollo: {
 },
 ```
 
-Then, because Etags depend on the request being a `GET` instead of GraphQL's usual `POST`, but our default link library does not support `GET` we need to let our default Apollo client know to use a different library.
+Then, because ETags depend on the request being a `GET` instead of GraphQL's usual `POST`, but our default link library does not support `GET` we need to let our default Apollo client know to use a different library.
 
 ```javascript
 /* componentMountIndex.js */

doc/development/gemfile.md

@@ -115,7 +115,7 @@ operator](https://thoughtbot.com/blog/rubys-pessimistic-operator))
 making it possible to upgrade `license_finder` or any other gem to a
 version that depends on `thor 1.2`.
 
-Simlarly, if `license_finder` had a vulnerability fixed in 6.0.1, we
+Similarly, if `license_finder` had a vulnerability fixed in 6.0.1, we
 should add:
 
 ```ruby
@@ -127,7 +127,7 @@ still depend on a newer version of `thor`, such as `6.0.2`, but would
 not be able to depend on the vulnerable version `6.0.0`.
 
 A downgrade like that could happen if we introduced a new dependency
-that also relied on thor but had its version pinned to a vulnerable
+that also relied on `thor` but had its version pinned to a vulnerable
 one. These changes are easy to miss in the `Gemfile.lock`. Pinning the
 version would result in a conflict that would need to be solved.
 

doc/development/go_guide/index.md

@@ -501,7 +501,7 @@ up to run `goimports -local gitlab.com/gitlab-org` so that it's applied to every
 
 ### Analyzer Tests
 
-The conventional Secure [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/) has a [`convert` function](https://gitlab.com/gitlab-org/security-products/analyzers/command/-/blob/main/convert.go#L15-17) that converts SAST/DAST scanner reports into [GitLab Security Reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas). When writing tests for the `convert` function, we should make use of [test fixtures](https://dave.cheney.net/2016/05/10/test-fixtures-in-go) using a `testdata` directory at the root of the analyzer's repo. The `testdata` directory should contain two subdirectories: `expect` and `reports`. The `reports` directory should contain sample SAST/DAST scanner reports which are passed into the `convert` function during the test setup. The `expect` directory should contain the expected GitLab Security Report that the `convert` returns. See Secret Detection for an [example](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/160424589ef1eed7b91b59484e019095bc7233bd/convert_test.go#L13-66).
+The conventional Secure [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/) has a [`convert` function](https://gitlab.com/gitlab-org/security-products/analyzers/command/-/blob/main/convert.go#L15-17) that converts SAST/DAST scanner reports into [GitLab Security Reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas). When writing tests for the `convert` function, we should make use of [test fixtures](https://dave.cheney.net/2016/05/10/test-fixtures-in-go) using a `testdata` directory at the root of the analyzer's repository. The `testdata` directory should contain two subdirectories: `expect` and `reports`. The `reports` directory should contain sample SAST/DAST scanner reports which are passed into the `convert` function during the test setup. The `expect` directory should contain the expected GitLab Security Report that the `convert` returns. See Secret Detection for an [example](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/160424589ef1eed7b91b59484e019095bc7233bd/convert_test.go#L13-66).
 
 If the scanner report is small, less than 35 lines, then feel free to [inline the report](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/blob/8bd2428a/convert/convert_test.go#L13-77) rather than use a `testdata` directory.
 

doc/development/stage_group_dashboards.md

@@ -25,7 +25,7 @@ The dashboards for stage groups are at a very early stage. All contributions are
 Read more about how we are using error budgets overall in our
 [handbook](https://about.gitlab.com/handbook/engineering/error-budgets/).
 
-By default, the first row of panels on the dashbhoard will show the [error
+By default, the first row of panels on the dashboard will show the [error
 budget for the stage
 group](https://about.gitlab.com/handbook/engineering/error-budgets/#budget-spend-by-stage-group). This
 row shows how the features owned by

doc/development/testing_guide/frontend_testing.md

@@ -1302,7 +1302,7 @@ A good guideline to follow: the more complex the component you may want to steer
 
 - To capture large data structures just to have something
 - To just have some kind of test written
-- To capture highly volatile ui elements without stubbing them (Think of GitLab UI version updates)
+- To capture highly volatile UI elements without stubbing them (Think of GitLab UI version updates)
 
 ---
 

doc/development/usage_ping/product_intelligence_review.md

@@ -48,7 +48,7 @@ Product Intelligence files.
   [Metrics Dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/usage_ping/dictionary.md) if it is needed.
 - Add a changelog [according to guidelines](../changelog.md).
 
-##### When adding or modifiying Snowplow events
+##### When adding or modifying Snowplow events
 
 - For frontend events, when relevant, add a screenshot of the event in
   the [testing tool](../snowplow/index.md#developing-and-testing-snowplow) used.
@@ -81,7 +81,7 @@ Any of the Product Intelligence engineers can be assigned for the Product Intell
   - Check if a [feature flag is needed](index.md#recommendations).
 - For tracking with Snowplow:
   - Check that the [event taxonomy](../snowplow/index.md#structured-event-taxonomy) is correct.
-  - Check the [usage recomendations](../snowplow/index.md#usage-recommendations).
+  - Check the [usage recommendations](../snowplow/index.md#usage-recommendations).
 - Metrics YAML definitions:
   - Check the metric `description`.
   - Check the metrics `key_path`.

doc/integration/elasticsearch.md

@@ -378,7 +378,7 @@ low may lead the reindexing process to take a very long time to complete.
 
 The best value for this will depend on your cluster size, whether you're willing
 to accept some degraded search performance during reindexing, and how important
-it is for the reindex to finish quickly and unpause indexing.
+it is for the reindex to finish quickly and resume indexing.
 
 ### Mark the most recent reindex job as failed and resume the indexing
 

doc/update/index.md

@@ -148,7 +148,7 @@ If you upgrade your GitLab instance while the GitLab Runner is processing jobs,
 
 As for the artifacts, the GitLab Runner will attempt to upload them three times, after which the job will eventually fail.
 
-To address the above two scenario's, it is adviced to do the following prior to upgrading:
+To address the above two scenario's, it is advised to do the following prior to upgrading:
 
 1. Plan your maintenance.
 1. Pause your runners.

doc/user/analytics/ci_cd_analytics.md

@@ -50,7 +50,7 @@ The following table shows the supported metrics, at which level they are support
 
 | Metric           | Level               | API version                                | Chart (UI) version                                     | Comments                                                                               |
 | --------------- | -----------               | ---------------                      | ----------                                      | -------                                                                               |
-| `deployment_frequency`    | Project-level       | [13.7+](../../api/dora/metrics.md)  | [13.8+](#deployment-frequency-charts) | The [old API endopint](../../api/dora4_project_analytics.md) was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/323713) in 13.10. |
+| `deployment_frequency`    | Project-level       | [13.7+](../../api/dora/metrics.md)  | [13.8+](#deployment-frequency-charts) | The [old API endpoint](../../api/dora4_project_analytics.md) was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/323713) in 13.10. |
 | `deployment_frequency`    | Group-level     | [13.10+](../../api/dora/metrics.md) | To be supported  |                                                                                       |
 | `lead_time_for_changes`   | Project-level      | [13.10+](../../api/dora/metrics.md) | [13.11+](#lead-time-charts)  | Unit in seconds. Aggregation method is median.                                                                    |
 | `lead_time_for_changes`   | Group-level     |  [13.10+](../../api/dora/metrics.md) | To be supported  | Unit in seconds. Aggregation method is median.                                                                    |

doc/user/application_security/container_scanning/index.md

@@ -324,7 +324,7 @@ To allowlist specific vulnerabilities, follow these steps:
 1. Set `GIT_STRATEGY: fetch` in your `.gitlab-ci.yml` file by following the instructions in
    [overriding the container scanning template](#overriding-the-container-scanning-template).
 1. Define the allowlisted vulnerabilities in a YAML file named `vulnerability-allowlist.yml`. This must use
-   the format described in [vulnerability-allowlist.yml data format](#vulnerability-allowlistyml-data-format).
+   the format described in [`vulnerability-allowlist.yml` data format](#vulnerability-allowlistyml-data-format).
 1. Add the `vulnerability-allowlist.yml` file to the root folder of your project's Git repository.
 
 #### vulnerability-allowlist.yml data format
@@ -365,9 +365,9 @@ This example excludes from `gl-container-scanning-report.json`:
 
   You can specify container image in multiple ways:
 
-  - as image name only (ie. `centos`).
-  - as full image name with registry hostname (ie. `your.private.registry:5000/centos`).
-  - as full image name with registry hostname and sha256 label (ie. `registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256`).
+  - as image name only (such as `centos`).
+  - as full image name with registry hostname (such as `your.private.registry:5000/centos`).
+  - as full image name with registry hostname and sha256 label (such as `registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256`).
 
 NOTE:
 The string after CVE ID (`cups` and `libxml2` in the previous example) is an optional comment format. It has **no impact** on the handling of vulnerabilities. You can include comments to describe the vulnerability.

doc/user/application_security/dast_api/index.md

@@ -594,7 +594,7 @@ can be added, removed, and modified by creating a custom configuration.
 - Application Information Check
 - Cleartext Authentication Check
 - FrameworkDebugModeCheck
-- Html Injection Check
+- HTML Injection Check
 - Insecure Http Methods Check
 - JSON Hijacking Check
 - JSON Injection Check
@@ -602,16 +602,16 @@ can be added, removed, and modified by creating a custom configuration.
 - Session Cookie Check
 - SQL Injection Check
 - Token Check
-- Xml Injection Check
+- XML Injection Check
 
 ##### Full
 
 - Application Information Check
 - Cleartext AuthenticationCheck
-- Cors Check
-- Dns Rebinding Check
+- CORS Check
+- DNS Rebinding Check
 - Framework Debug Mode Check
-- Html Injection Check
+- HTML Injection Check
 - Insecure Http Methods Check
 - JSON Hijacking Check
 - JSON Injection Check
@@ -620,9 +620,9 @@ can be added, removed, and modified by creating a custom configuration.
 - Sensitive Information Check
 - Session Cookie Check
 - SQL Injection Check
-- Tls Configuration Check
+- TLS Configuration Check
 - Token Check
-- Xml Injection Check
+- XML Injection Check
 
 ### Available CI/CD variables
 

doc/user/application_security/dependency_scanning/index.md

@@ -510,7 +510,7 @@ ensure that it can reach your private repository. Here is an example configurati
 
 ## Hosting a copy of the gemnasium_db advisory database
 
-The [gemnasium_db](https://gitlab.com/gitlab-org/security-products/gemnasium-db) Git repository is
+The [`gemnasium_db`](https://gitlab.com/gitlab-org/security-products/gemnasium-db) Git repository is
 used by `gemnasium`, `gemnasium-maven`, and `gemnasium-python` as the source of vulnerability data.
 This repository updates at scan time to fetch the latest advisories. However, due to a restricted
 networking environment, running this update is sometimes not possible. In this case, a user can do

doc/user/application_security/sast/index.md

@@ -710,7 +710,7 @@ documentation for instructions.
 
 ## Running SAST in SELinux
 
-By default SAST analyzers are supported in GitLab instances hosted on SELinux. Adding a `before_script` in an [overriden SAST job](#overriding-sast-jobs) may not work as runners hosted on SELinux have restricted permissions.
+By default SAST analyzers are supported in GitLab instances hosted on SELinux. Adding a `before_script` in an [overridden SAST job](#overriding-sast-jobs) may not work as runners hosted on SELinux have restricted permissions.
 
 ## Troubleshooting
 

doc/user/clusters/agent/index.md

@@ -562,7 +562,7 @@ is unknown to the agent. One approach to fixing it is to present the CA certific
 via a Kubernetes `configmap` and mount the file in the agent `/etc/ssl/certs` directory from where it
 will be picked up automatically.
 
-For example, if your internal CA certifciate is `myCA.pem`:
+For example, if your internal CA certificate is `myCA.pem`:
 
 ```plaintext
 kubectl -n gitlab-kubernetes-agent create configmap ca-pemstore --from-file=myCA.pem

doc/user/group/devops_adoption/index.md

@@ -114,7 +114,7 @@ To disable it:
 Feature.disable(:group_devops_adoption)
 ```
 
-To reenable it:
+To re-enable it:
 
 ```ruby
 Feature.enable(:group_devops_adoption)

doc/user/project/deploy_keys/index.md

@@ -167,7 +167,7 @@ If the key is **publicly accessible**, it will be removed from the project, but
 
 If the key is **privately accessible** and only in use by this project, it will deleted.
 
-If the key is **privately accessible** and in use by other projects, it will be removed from the project, but still available under **Privately accesible deploy keys**.
+If the key is **privately accessible** and in use by other projects, it will be removed from the project, but still available under **Privately accessible deploy keys**.
 
 ## Troubleshooting
 

doc/user/project/integrations/hangouts_chat.md

@@ -15,7 +15,7 @@ Hangouts).
 ## How it works
 
 To enable this integration, first you need to create a webhook for the room in
-Google Chat where you want to receive the nofications from your project.
+Google Chat where you want to receive the notifications from your project.
 
 After that, enable the integration in GitLab and choose the events you want to
 be notified about in your Google Chat room.

doc/user/project/repository/branches/index.md

@@ -103,7 +103,7 @@ Sometimes when you have hundreds of branches you may want a more flexible matchi
 
 ![Before swap revisions](img/swap_revisions_before_v13_12.png)
 
-The Swap revisions feature allows you to swap the Source and Target revisions. When the Swap revisions button is clicked, the selected revisions for Source and Targed will be swapped.
+The Swap revisions feature allows you to swap the Source and Target revisions. When the Swap revisions button is clicked, the selected revisions for Source and Target will be swapped.
 
 ![After swap revisions](img/swap_revisions_after_v13_12.png)