Merge branch 'docs-aqualls-exception-list' into 'master'

Resolve more spelling issues

See merge request gitlab-org/gitlab!53799

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

@@ -9,6 +9,7 @@ allowlist
 allowlisted
 allowlisting
 allowlists
+anonymization
 anonymized
 Ansible
 Anthos
@@ -81,6 +82,7 @@ Caddy
 callstack
 callstacks
 Camo
+canonicalized
 CentOS
 Certbot
 changeset
@@ -359,6 +361,8 @@ Nanoc
 negatable
 Netlify
 Nokogiri
+noteable
+noteables
 npm
 nullability
 nullable
@@ -689,6 +693,7 @@ unreplicated
 unresolve
 unresolved
 unresolving
+unsanitized
 unschedule
 unscoped
 unshare
@@ -736,6 +741,7 @@ WebdriverIO
 Webex
 webpack
 webserver
+Webservice
 websocket
 websockets
 whitepaper

doc/architecture/blueprints/database_testing/index.md

@@ -17,11 +17,11 @@ Developers are expected to test database migrations prior to deploying to any en
 
 The [code review phase](../../../development/database_review.md) involves Database Reviewers and Maintainers to manually check the migrations committed. This often involves knowing and spotting problematic patterns and their particular behavior on GitLab.com from experience. There is no large-scale environment available that allows us to test database migrations before they are being merged.
 
-Testing in CI is done on a very small database. We mainly check forward/backward migration consistency, evaluate rubocop rules to detect well-known problematic behaviors (static code checking) and have a few other, rather technical checks in place (adding the right files etc). That is, we typically find code or other rather simple errors, but cannot surface any data related errors - which are also typically not covered by unit tests either.
+Testing in CI is done on a very small database. We mainly check forward/backward migration consistency, evaluate Rubocop rules to detect well-known problematic behaviors (static code checking) and have a few other, rather technical checks in place (adding the right files etc). That is, we typically find code or other rather simple errors, but cannot surface any data related errors - which are also typically not covered by unit tests either.
 
 Once merged, migrations are being deployed to the staging environment. Its database size is less than 5% of the production database size as of January 2021 and its recent data distribution does not resemble the production site. Oftentimes, we see migrations succeed in staging but then fail in production due to query timeouts or other unexpected problems. Even if we caught problems in staging, this is still expensive to reconcile and ideally we want to catch those problems as early as possible in the development cycle.
 
-Today, we have gained experience with working on a thin-cloned production database (more on this below) and already use it to provide developers with access to production query plans, automated query feedback and suggestions with optimizations. This is built around [Database Lab](https://gitlab.com/postgres-ai/database-lab) and [Joe](https://gitlab.com/postgres-ai/joe), both available through Slack (using chatops) and [postgres.ai](https://postgres.ai/).
+Today, we have gained experience with working on a thin-cloned production database (more on this below) and already use it to provide developers with access to production query plans, automated query feedback and suggestions with optimizations. This is built around [Database Lab](https://gitlab.com/postgres-ai/database-lab) and [Joe](https://gitlab.com/postgres-ai/joe), both available through Slack (using ChatOps) and [postgres.ai](https://postgres.ai/).
 
 ## Vision
 
@@ -97,7 +97,7 @@ The short-term goal is detailed in [this epic](https://gitlab.com/groups/gitlab-
 
 ### Mid-term - Improved feedback, query testing and background migration testing
 
-Mid-term, we plan to expand the level of detail the testing pipeline reports back to the Merge Request and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (postgres.ai, joe, Slack, plan visualizations etc.) we bring this back to GitLab and working directly on the Merge Request.
+Mid-term, we plan to expand the level of detail the testing pipeline reports back to the Merge Request and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (`postgres.ai`, `joe`, Slack, plan visualizations etc.) we bring this back to GitLab and working directly on the Merge Request.
 
 Secondly, we plan to cover background migrations testing, too. These are typically data migrations that are scheduled to run over a long period of time. The success of both the scheduling phase and the job execution phase typically depends a lot on data distribution - which only surfaces when running these migrations on actual production data. In order to become confident about a background migration, we plan to provide the following feedback:
 
@@ -122,10 +122,10 @@ An alternative approach we have discussed and abandoned is to "scrub" and anonym
 
 ## Who
 
-This effort is owned and driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/database/) with support from the [GitLab.com Reliability Datastores](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/datastores/) team.
-
 <!-- vale gitlab.Spelling = NO -->
 
+This effort is owned and driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/database/) with support from the [GitLab.com Reliability Datastores](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/datastores/) team.
+
 | Role                         | Who
 |------------------------------|-------------------------|
 | Author                       |    Andreas Brandl       |

doc/development/testing_guide/frontend_testing.md

@@ -548,8 +548,12 @@ In order to ensure that a clean wrapper object and DOM are being used in each te
   });
 ```
 
+<!-- vale gitlab.Spelling = NO -->
+
 See also the [Vue Test Utils documentation on `destroy`](https://vue-test-utils.vuejs.org/api/wrapper/#destroy).
 
+<!-- vale gitlab.Spelling = YES -->
+
 ### Jest best practices
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34209) in GitLab 13.2.
@@ -646,7 +650,7 @@ The latter is useful when you have `setInterval` in the code. **Remember:** our
 
 Non-determinism is the breeding ground for flaky and brittle specs. Such specs end up breaking the CI pipeline, interrupting the work flow of other contributors.
 
-1. Make sure your test subject's collaborators (e.g., axios, apollo, lodash helpers) and test environment (e.g., Date) behave consistently across systems and over time.
+1. Make sure your test subject's collaborators (e.g., Axios, apollo, Lodash helpers) and test environment (e.g., Date) behave consistently across systems and over time.
 1. Make sure tests are focused and not doing "extra work" (e.g., needlessly creating the test subject more than once in an individual test)
 
 ### Faking `Date` for determinism
@@ -807,7 +811,7 @@ yarn karma -f 'spec/javascripts/ide/**/file_spec.js'
 ## Frontend test fixtures
 
 Frontend fixtures are files containing responses from backend controllers. These responses can be either HTML
-generated from haml templates or JSON payloads. Frontend tests that rely on these responses are
+generated from HAML templates or JSON payloads. Frontend tests that rely on these responses are
 often using fixtures to validate correct integration with the backend code.
 
 ### Generate fixtures
@@ -1042,7 +1046,7 @@ import _Thing from '~/feature/path/to/thing.vue';
 NOTE:
 Do not disregard test timeouts. This could be a sign that there's
 actually a production problem. Use this opportunity to analyze the production webpack bundles and
-chunks and confirm that there is not a production issue with the async imports.
+chunks and confirm that there is not a production issue with the asynchronous imports.
 
 ## Overview of Frontend Testing Levels
 
@@ -1092,9 +1096,13 @@ Check an example in [`spec/frontend/ide/stores/actions_spec.js`](https://gitlab.
 
 ### Wait until Axios requests finish
 
+<!-- vale gitlab.Spelling = NO -->
+
 The Axios Utils mock module located in `spec/frontend/mocks/ce/lib/utils/axios_utils.js` contains two helper methods for Jest tests that spawn HTTP requests.
 These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its life cycle.
 
+<!-- vale gitlab.Spelling = YES -->
+
 - `waitFor(url, callback)`: Runs `callback` after a request to `url` finishes (either successfully or unsuccessfully).
 - `waitForAll(callback)`: Runs `callback` once all pending requests have finished. If no requests are pending, runs `callback` on the next tick.
 

doc/development/transient/prevention-patterns.md

@@ -25,7 +25,7 @@ If your feature requires data from both, ensure that the two have finished loadi
 
 ### Simulate slower connections when testing manually
 
-Add a network condition template to your browser's dev tools to enable you to toggle between a slow and a fast connection.
+Add a network condition template to your browser's developer tools to enable you to toggle between a slow and a fast connection.
 
 **Example:**
 
@@ -40,7 +40,7 @@ When setting event listeners, if not possible to use event delegation, ensure al
 
 Including when that expanded content is:
 
-- **Invisible** (`display: none;`). Some JavaScript requires the element to be visible to work properly (eg.: when taking measurements).
+- **Invisible** (`display: none;`). Some JavaScript requires the element to be visible to work properly, such as when taking measurements.
 - **Dynamic content** (AJAX/DOM manipulation).
 
 ### Using assertions to detect transient bugs caused by unmet conditions

doc/integration/elasticsearch.md

@@ -305,7 +305,7 @@ and Elasticsearch index alias feature to perform the operation. We set up an ind
 `primary` index which is used by GitLab for reads/writes. When reindexing process starts, we temporarily pause
 the writes to the `primary` index. Then, we create another index and invoke the Reindex API which migrates the
 index data onto the new index. Once the reindexing job is complete, we switch to the new index by connecting the
-index alias to it which becomes the new `primary` index. At the end, we unpause the writes and normal operation resumes.
+index alias to it which becomes the new `primary` index. At the end, we resume the writes and normal operation resumes.
 
 ### Trigger the reindex via the Advanced Search administration
 

doc/topics/cron/index.md

@@ -64,6 +64,6 @@ More examples of how to write a cron schedule can be found at
 
 ## How GitLab parses cron syntax strings
 
-GitLab uses [fugit](https://github.com/floraison/fugit) to parse cron syntax
+GitLab uses [`fugit`](https://github.com/floraison/fugit) to parse cron syntax
 strings on the server and [cron-validate](https://github.com/Airfooox/cron-validate)
 to validate cron syntax in the browser.