diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index 62517bbf150c8837026592a82df08b086627fb6f..e6a853c107ee0c482e7dba9b3de0882e96e59823 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -116,7 +116,7 @@ Please raise an issue in the GitLab CE or EE repositories to report the issue. I ~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the `TooManyInvocationsError`. Also include any known failing tests if possible. -Isolate the source of the n+1 problem. This is normally a loop that results in Gitaly being called for each +Isolate the source of the n+1 problem. This is usually a loop that results in Gitaly being called for each element in an array. If you are unable to isolate the problem, please contact a member of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance. @@ -152,7 +152,7 @@ end ## Running tests with a locally modified version of Gitaly -Normally, GitLab CE/EE tests use a local clone of Gitaly in +Usually, GitLab CE/EE tests use a local clone of Gitaly in `tmp/tests/gitaly` pinned at the version specified in `GITALY_SERVER_VERSION`. The `GITALY_SERVER_VERSION` file supports also branches and SHA to use a custom commit in [the repository](https://gitlab.com/gitlab-org/gitaly). diff --git a/doc/development/graphql_guide/batchloader.md b/doc/development/graphql_guide/batchloader.md index 7a0611fdb16f64caae5ebca586aa70da7ab8101d..5f06f1faf1e8f94eac8ff3efccdc9748b7a28666 100644 --- a/doc/development/graphql_guide/batchloader.md +++ b/doc/development/graphql_guide/batchloader.md @@ -161,7 +161,7 @@ you do so, you do not need to manage the lifecycle of lazy values yourself, and you are assured accurate results. GraphQL fields that return lazy values may need these values forced in tests. -Forcing refers to explicit demands for evaluation, where this would normally +Forcing refers to explicit demands for evaluation, where this would usually be arranged by the framework. You can force a lazy value with the `GraphqlHelpers#batch_sync` method available in [GraphQLHelpers](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/helpers/graphql_helpers.rb), or by using `Gitlab::Graphql::Lazy.force`. For example: diff --git a/doc/development/internal_analytics/service_ping/implement.md b/doc/development/internal_analytics/service_ping/implement.md index e171490068fcffc01b1f04befeee7348cc675ed3..3b8243377a3a169719245604998693cbe4aaec94 100644 --- a/doc/development/internal_analytics/service_ping/implement.md +++ b/doc/development/internal_analytics/service_ping/implement.md @@ -783,7 +783,7 @@ By default, it comes with a fully configured Prometheus service that is set up t However, it has the following limitations: - It does not run a `gitlab-exporter` instance, so several `process_*` metrics from services such as Gitaly may be missing. -- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it normally reports itself as not associated +- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it usually reports itself as not associated with any of the other running services. That is not how node metrics are reported in a production setup, where `node_exporter` always runs as a process alongside other GitLab components on any given node. For Service Ping, none of the node data would therefore appear to be associated to any of the services running, because they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Service Ping. diff --git a/doc/development/performance.md b/doc/development/performance.md index 291165d81254030aeada7132f4abe46d5ea3273d..fd7e9a85fba279634a4b34ac30cf3d305ee4ec38 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -217,7 +217,7 @@ Finished in 18.19 seconds (files took 4.8 seconds to load) ``` You can limit the specs that are run by passing any arguments `RSpec` would -normally take. +usually take. ### Using Stackprof in production diff --git a/doc/development/sidekiq/idempotent_jobs.md b/doc/development/sidekiq/idempotent_jobs.md index 1c4f4ba44a819ea0b0a8eea968426f26e5abe06d..8ccbeee283d8225a769537af270f1b081a2638ae 100644 --- a/doc/development/sidekiq/idempotent_jobs.md +++ b/doc/development/sidekiq/idempotent_jobs.md @@ -156,7 +156,7 @@ end ## Setting the deduplication time-to-live (TTL) -Deduplication depends on an idempotent key that is stored in Redis. This is normally +Deduplication depends on an idempotent key that is stored in Redis. This is usually cleared by the configured deduplication strategy. However, the key can remain until its TTL in certain cases like: diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md index 7970f9711e6c396c3602fe4f99b48e376157eed3..a6de6f594fbbb83c959d0b677562c2e8da695089 100644 --- a/doc/policy/maintenance.md +++ b/doc/policy/maintenance.md @@ -102,7 +102,7 @@ accessible. ### Backporting to older releases -Backporting to more than one stable release is normally reserved for [security releases](#security-releases). +Backporting to more than one stable release is usually reserved for [security releases](#security-releases). In some cases, however, we may need to backport *a bug fix* to more than one stable release, depending on the severity of the bug. diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md index 1e4d5f14a180db7152de7fb5b645e04c929cd042..4c77323778cd6235a8ac4497dc35a369ca906e3f 100644 --- a/doc/user/project/file_lock.md +++ b/doc/user/project/file_lock.md @@ -147,7 +147,7 @@ permissions to the project: git lfs unlock --id=123 --force ``` -You can normally push files to GitLab whether they're locked or unlocked. +You can push files to GitLab whether they're locked or unlocked. NOTE: Although multi-branch file locks can be created and managed through the Git LFS diff --git a/doc/user/project/releases/release_evidence.md b/doc/user/project/releases/release_evidence.md index 3269bf8f44bdae66f9a8ce2cf94dee277240c7b3..990945b1a2b3f5c475ccffa474c79d175a3a19b1 100644 --- a/doc/user/project/releases/release_evidence.md +++ b/doc/user/project/releases/release_evidence.md @@ -97,7 +97,7 @@ Evidence collection snapshots are visible on the Releases page, along with the t When you create a release, if [job artifacts](../../../ci/yaml/index.md#artifactsreports) are included in the last pipeline that ran, they are automatically included in the release as release evidence. -Although job artifacts normally expire, artifacts included in release evidence do not expire. +Although job artifacts usually expire, artifacts included in release evidence do not expire. To enable job artifact collection you must specify both: