Resolve more spelling issues in the docs

Handle another round of spelling issues in whatever ways seem best.

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

@@ -41,6 +41,7 @@ autoscales
 autoscaling
 awardable
 awardables
+Ayoa
 Axios
 Azure
 B-tree
@@ -111,6 +112,8 @@ Contentful
 Corosync
 Coursier
 cron
+cronjob
+cronjobs
 crons
 crontab
 crontabs
@@ -280,6 +283,7 @@ kaniko
 Karma
 Kerberos
 keyset
+keyspace
 keytab
 keytabs
 Kibana
@@ -350,6 +354,7 @@ mixins
 mockup
 mockups
 ModSecurity
+Monokai
 monorepo
 monorepos
 multiline
@@ -408,6 +413,7 @@ pooler
 postgres.ai
 PostgreSQL
 precompile
+precompiled
 preconfigure
 preconfigured
 preconfigures
@@ -445,6 +451,7 @@ queryable
 Quicktime
 Rackspace
 Raspbian
+rbtrace
 Rdoc
 reachability
 Realplayer
@@ -479,6 +486,7 @@ reinitialize
 reinitializing
 relicensing
 remediations
+replicables
 repmgr
 repmgrd
 repurposing
@@ -521,6 +529,7 @@ Salesforce
 sandboxing
 sanitization
 sbt
+scalers
 scatterplot
 scatterplots
 Schemastore
@@ -546,6 +555,7 @@ Slackbot
 Slony
 smartcard
 smartcards
+snapshotting
 Sobelow
 Solarized
 Sourcegraph
@@ -564,6 +574,7 @@ strace
 strikethrough
 strikethroughs
 stunnel
+stylelint
 subfolder
 subfolders
 subgraph
@@ -629,6 +640,7 @@ toolkit
 toolkits
 tooltip
 tooltips
+transactionally
 transpile
 transpiled
 transpiles
@@ -637,6 +649,7 @@ Trello
 triaged
 triages
 triaging
+Trivy
 truthy
 Truststore
 Twilio

doc/development/documentation/testing.md

@@ -272,7 +272,11 @@ To configure Vale in your editor, install one of the following as appropriate:
   In the extension's settings:
   - Select the **Use CLI** checkbox.
-  - In the **Config** setting, enter an absolute path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini) in one of the cloned GitLab repositories on your computer.
+  - In the <!-- vale gitlab.Spelling = NO --> **Config** setting, enter an absolute
+    path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini)
+    in one of the cloned GitLab repositories on your computer.
+    <!-- vale gitlab.Spelling = YES -->
+
   - In the **Path** setting, enter the absolute path to the Vale binary. In most
     cases, `vale` should work. To find the location, run `which vale` in a terminal.

doc/development/image_scaling.md

@@ -73,7 +73,7 @@ we simply follow the path we take to serve any ordinary upload.
 ### Workhorse
 Assuming Rails decided the request to be valid, Workhorse will take over. Upon receiving the `send-scaled-image`
-instruction through the Rails response, a [special response injecter](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
+instruction through the Rails response, a [special response injector](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
 will be invoked that knows how to rescale images. The only inputs it requires are the location of the image
 (a path if the image resides in block storage, or a URL to remote storage otherwise) and the desired width.
 Workhorse will handle the location transparently so Rails does not need to be concerned with where the image

doc/development/namespaces_storage_statistics.md

@@ -140,7 +140,7 @@ Even though this approach would make aggregating much easier, it has some major
 - We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost would be significant. The background migration would take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29772>.
 - Background migration has to be shipped one release before, delaying the functionality by another milestone.
-### Attempt E (final): Update the namespace storage statistics in async way
+### Attempt E (final): Update the namespace storage statistics asynchronously
 This approach consists of continuing to use the incremental statistics updates we already have,
 but we refresh them through Sidekiq jobs and in different transactions:
@@ -149,7 +149,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
 1. Whenever the statistics of a project changes, insert a row into `namespace_aggregation_schedules`
    - We don't insert a new row if there's already one related to the root namespace.
    - Keeping in mind the length of the transaction that involves updating `project_statistics`(<https://gitlab.com/gitlab-org/gitlab/-/issues/29070>), the insertion should be done in a different transaction and through a Sidekiq Job.
-1. After inserting the row, we schedule another worker to be executed async at two different moments:
+1. After inserting the row, we schedule another worker to be executed asynchronously at two different moments:
    - One enqueued for immediate execution and another one scheduled in `1.5h` hours.
    - We only schedule the jobs, if we can obtain a `1.5h` lease on Redis on a key based on the root namespace ID.
    - If we can't obtain the lease, it indicates there's another aggregation already in progress, or scheduled in no more than `1.5h`.
@@ -161,7 +161,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
 This implementation has the following benefits:
-- All the updates are done async, so we're not increasing the length of the transactions for `project_statistics`.
+- All the updates are done asynchronously, so we're not increasing the length of the transactions for `project_statistics`.
 - We're doing the update in a single SQL query.
 - It is compatible with PostgreSQL and MySQL.
 - No background migration required.

doc/development/new_fe_guide/development/components.md

@@ -19,7 +19,7 @@ D3 is very popular across many projects outside of GitLab:
 - [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
 - [plot.ly](https://plotly.com/)
-- [Droptask](https://www.ayoa.com/previously-droptask/)
+- [Ayoa](https://www.ayoa.com/previously-droptask/)
 Within GitLab, D3 has been used for the following notable features

doc/development/performance.md

@@ -256,7 +256,7 @@ The following configuration options can be configured:
 - `STACKPROF_MODE`: See [sampling modes](https://github.com/tmm1/stackprof#sampling).
   Defaults to `cpu`.
 - `STACKPROF_INTERVAL`: Sampling interval. Unit semantics depend on `STACKPROF_MODE`.
-  For `object` mode this is a per-event interval (every `n`th event is sampled)
+  For `object` mode this is a per-event interval (every `nth` event is sampled)
   and defaults to `1000`.
   For other modes such as `cpu` this is a frequency and defaults to `10000` μs (100hz).
 - `STACKPROF_FILE_PREFIX`: File path prefix where profiles are stored. Defaults
@@ -293,7 +293,7 @@ worker processes), selecting the latter.
 For Sidekiq, the signal can be sent to the `sidekiq-cluster` process via `pkill
 -USR2 bin/sidekiq-cluster`, which forwards the signal to all Sidekiq
-children. Alternatively, you can also select a specific pid of interest.
+children. Alternatively, you can also select a specific PID of interest.
 Production profiles can be especially noisy. It can be helpful to visualize them
 as a [flame graph](https://github.com/brendangregg/FlameGraph). This can be done
@@ -306,7 +306,7 @@ bundle exec stackprof --stackcollapse /tmp/stackprof.55769.c6c3906452.profile |
 ## RSpec profiling
 The GitLab development environment also includes the
-[rspec_profiling](https://github.com/foraker/rspec_profiling) gem, which is used
+[`rspec_profiling`](https://github.com/foraker/rspec_profiling) gem, which is used
 to collect data on spec execution times. This is useful for analyzing the
 performance of the test suite itself, or seeing how the performance of a spec
 may have changed over time.
@@ -409,7 +409,7 @@ Fragmented Ruby heap snapshot could look like this:
 ![Ruby heap fragmentation](img/memory_ruby_heap_fragmentation.png)
-Memory fragmentation could be reduced by tuning GC parameters as described in [this post by Nate Berkopec](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
+Memory fragmentation could be reduced by tuning GC parameters [as described in this post](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
 ## Importance of Changes

doc/development/query_performance.md

@@ -25,7 +25,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.
-- If an existing query is already underperforming, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.
+- If an existing query is not performing well, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.
 ## Cold and warm cache

doc/development/redis.md

@@ -120,14 +120,13 @@ This shows commands that have taken a long time and may be a performance
 concern.
 The
-[fluent-plugin-redis-slowlog](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
-project is responsible for taking the slowlog entries from Redis and
-passing to fluentd (and ultimately Elasticsearch).
+[`fluent-plugin-redis-slowlog`](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
+project is responsible for taking the `slowlog` entries from Redis and
+passing to Fluentd (and ultimately Elasticsearch).
 ## Analyzing the entire keyspace
-The [Redis Keyspace
-Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
+The [Redis Keyspace Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
 project contains tools for dumping the full key list and memory usage of a Redis
 instance, and then analyzing those lists while eliminating potentially sensitive
 data from the results. It can be used to find the most frequent key patterns, or

doc/development/secure_coding_guidelines.md

@@ -195,7 +195,7 @@ Go's [`regexp`](https://golang.org/pkg/regexp/) package uses `re2` and isn't vul
 - [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
 - [Runaway Regular Expressions](https://www.regular-expressions.info/catastrophic.html)
 - [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](https://people.cs.vt.edu/~davisjam/downloads/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
-- [Freezing the web: A study of redos vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
+- [Freezing the web: A study of ReDoS vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
 ## Server Side Request Forgery (SSRF)

doc/development/sidekiq_style_guide.md

@@ -588,7 +588,7 @@ the `.with_route` scope defined on all `Routable`s.
 ### Cron workers
-The context is automatically cleared for workers in the Cronjob queue
+The context is automatically cleared for workers in the cronjob queue
 (`include CronjobQueue`), even when scheduling them from
 requests. We do this to avoid incorrect metadata when other jobs are
 scheduled from the cron worker.

doc/development/testing_guide/best_practices.md

@@ -800,10 +800,11 @@ end
 ```
 WARNING:
-Only use simple values as input in the `where` block. Using procs, stateful
+Only use simple values as input in the `where` block. Using
+<!-- vale gitlab.Spelling = NO --> procs, stateful
 objects, FactoryBot-created objects, and similar items can lead to
 [unexpected results](https://github.com/tomykaira/rspec-parameterized/issues/8).
-
+<!-- vale gitlab.Spelling = YES -->
 ### Prometheus tests
 Prometheus metrics may be preserved from one test run to another. To ensure that metrics are

doc/development/testing_guide/frontend_testing.md

@@ -687,7 +687,7 @@ Similarly, if you really need to use the real `Date` class, then you can import
 ```javascript
 import { useRealDate } from 'helpers/fake_date';
-// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.). 
+// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.).
 describe('with real date', () => {
   useRealDate();
 });
@@ -1034,7 +1034,7 @@ describe "Admin::AbuseReports", :js do
 end
 ```
-### Jest test timeout due to async imports
+### Jest test timeout due to asynchronous imports
 If a module asynchronously imports some other modules at runtime, these modules must be
 transpiled by the Jest loaders at runtime. It's possible that this can cause [Jest to timeout](https://gitlab.com/gitlab-org/gitlab/-/issues/280809).

doc/integration/saml.md

@@ -13,15 +13,15 @@ You should also reference the [OmniAuth documentation](omniauth.md) for general
 ## Common SAML Terms
-| Term | Description |
-|------|-------------|
-| Identity Provider (IdP) | The service which manages your user identities such as ADFS, Okta, Onelogin, or Ping Identity. |
-| Service Provider (SP) | SAML considers GitLab to be a service provider. |
-| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
-| SSO | Single Sign-On. |
+| Term                           | Description |
+|--------------------------------|-------------|
+| Identity Provider (IdP)        | The service which manages your user identities, such as ADFS, Okta, OneLogin, or Ping Identity. |
+| Service Provider (SP)          | SAML considers GitLab to be a service provider. |
+| Assertion                      | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
+| SSO                            | Single Sign-On. |
 | Assertion consumer service URL | The callback on GitLab where users will be redirected after successfully authenticating with the identity provider. |
-| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
-| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
+| Issuer                         | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
+| Certificate fingerprint        | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
 ## General Setup
@@ -265,7 +265,7 @@ considered admin users.
 ### Auditor groups **(PREMIUM SELF)**
-> Introduced in [GitLab Starter](https://about.gitlab.com/pricing/) 11.4.
+> Introduced in GitLab 11.4.
 The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell
 GitLab where to look for the groups in the SAML response, and which group(s) should be
@@ -454,8 +454,6 @@ args: {
 ### `uid_attribute`
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17734) in GitLab 10.7.
-
 By default, the `uid` is set as the `name_id` in the SAML response. If you'd like to designate a unique attribute for the `uid`, you can set the `uid_attribute`. In the example below, the value of `uid` attribute in the SAML response is set as the `uid_attribute`.
 ```yaml

doc/ssh/README.md

@@ -77,7 +77,7 @@ If you do not have an existing SSH key pair, generate a new one.
 1. Type `ssh-keygen -t` followed by the key type and an optional comment.
    This comment is included in the `.pub` file that's created.
    You may want to use an email address for the comment.
-  
+
    For example, for ED25519:
    ```shell
@@ -111,7 +111,7 @@ If you do not have an existing SSH key pair, generate a new one.
 1. A confirmation is displayed, including information about where your files are stored.
-A public and private key are generated. 
+A public and private key are generated.
 [Add the public SSH key to your GitLab account](#add-an-ssh-key-to-your-gitlab-account) and keep
 the private key secure.
@@ -278,7 +278,7 @@ Instead, you can assign aliases to hosts in the `~.ssh/config` file.
 - For the `Host`, use an alias like `user_1.gitlab.com` and
   `user_2.gitlab.com`. Advanced configurations
   are more difficult to maintain, and these strings are easier to
-  understand when you use tools like `git remote`. 
+  understand when you use tools like `git remote`.
 - For the `IdentityFile`, use the path the private key.
 ```conf

doc/topics/autodevops/index.md

@@ -46,8 +46,12 @@ From [AlexJonesax](https://twitter.com/AlexJonesax) and [KaiPMDH](https://twitte
 ![Alex on Twitter: Auto DevOps in GitLab doesn't just lower the bar to entry, it removes the bar and holds your hand.](img/alexj_autodevops_min_v13_8.png)
+<!-- vale gitlab.Spelling = NO -->
+
 ![Kai on Twitter: When I saw this on the Auto DevOps stuff, my mind was blown...](img/kai_autodevops_min_v13_8.png)
+<!-- vale gitlab.Spelling = YES -->
+
 We welcome everyone to [share your experience by tagging GitLab on Twitter](https://twitter.com/gitlab).
 ## Enabled by default

doc/topics/autodevops/stages.md

@@ -103,7 +103,9 @@ NOTE:
 Not all buildpacks supported by [Auto Build](#auto-build) are supported by Auto Test.
 Auto Test uses [Herokuish](https://gitlab.com/gitlab-org/gitlab/-/issues/212689), *not*
 Cloud Native Buildpacks, and only buildpacks that implement the
+<!-- vale gitlab.Spelling = NO -->
 [Testpack API](https://devcenter.heroku.com/articles/testpack-api) are supported.
+<!-- vale gitlab.Spelling = YES -->
 ### Currently supported languages