Commit e63e5605 authored by Marcel Amirault's avatar Marcel Amirault

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

Resolve more spelling issues

See merge request gitlab-org/gitlab!53799
parents fe2079f9 c9776cb9
......@@ -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
......
......@@ -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 |
......
......@@ -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.
......
......@@ -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
......
......@@ -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
......
......@@ -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.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment