From 61da5384e3409ca4619f562b2cb7c8bc6dc3ffb4 Mon Sep 17 00:00:00 2001
From: Marcel Amirault <mamirault@gitlab.com>
Date: Fri, 3 Dec 2021 14:46:01 +0000
Subject: [PATCH] Run whitespace cleanup
---
doc/administration/audit_events.md | 2 +-
doc/administration/auth/ldap/index.md | 4 +-
.../geo/secondary_proxy/index.md | 2 +-
doc/administration/instance_limits.md | 2 +-
.../repository_storage_types.md | 4 +-
doc/api/members.md | 6 +--
doc/ci/git_submodules.md | 2 +-
doc/ci/pipelines/merge_trains.md | 2 +-
doc/development/adding_database_indexes.md | 4 +-
.../contributing/merge_request_workflow.md | 2 +-
doc/development/fe_guide/vue.md | 2 +-
doc/development/fe_guide/vue3_migration.md | 2 +-
doc/development/service_ping/implement.md | 2 +-
doc/development/service_ping/index.md | 6 +--
doc/development/sidekiq_style_guide.md | 2 +-
doc/development/snowplow/implementation.md | 38 +++++++++----------
doc/integration/elasticsearch.md | 2 +-
doc/integration/jira/dvcs.md | 2 +-
doc/security/webhooks.md | 2 +-
doc/subscriptions/gitlab_com/index.md | 2 +-
doc/topics/cron/index.md | 2 +-
doc/update/deprecations.md | 2 +-
doc/user/admin_area/index.md | 2 +-
doc/user/analytics/index.md | 28 +++++++-------
doc/user/analytics/productivity_analytics.md | 14 +++----
.../application_security/api_fuzzing/index.md | 2 +-
.../dast/browser_based.md | 2 +-
doc/user/application_security/dast/index.md | 2 +-
doc/user/application_security/index.md | 2 +-
.../security_dashboard/index.md | 2 +-
doc/user/clusters/agent/index.md | 2 +-
doc/user/clusters/agent/install/index.md | 2 +-
.../compliance/license_compliance/index.md | 6 +--
doc/user/group/devops_adoption/index.md | 16 ++++----
doc/user/group/index.md | 2 +-
doc/user/group/saml_sso/index.md | 6 +--
.../group/value_stream_analytics/index.md | 6 +--
doc/user/profile/index.md | 2 +-
.../repository/gpg_signed_commits/index.md | 2 +-
39 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 11790e3a58ef9..7c597bd5f0fb1 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -208,7 +208,7 @@ Events visible in Audit Events views until more events are logged.
### "Deleted User" events
-Audit events can be created for a user after the user is deleted. The user name associated with the event is set to
+Audit events can be created for a user after the user is deleted. The user name associated with the event is set to
"Deleted User" because the actual user name is unknowable. For example, if a deleted user's access to a project is
removed automatically due to expiration, the audit event is created for "Deleted User". We are [investigating](https://gitlab.com/gitlab-org/gitlab/-/issues/343933)
whether this is avoidable.
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index d2a783972dced..f551c36278412 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -23,7 +23,7 @@ Users added through LDAP:
- Take a [licensed seat](../../../subscriptions/self_managed/index.md#billable-users).
- Can authenticate with Git using either their GitLab username or their email and LDAP password,
- even if password authentication for Git
+ even if password authentication for Git
[is disabled](../../../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
The LDAP DN is associated with existing GitLab users when:
@@ -41,7 +41,7 @@ If an existing GitLab user wants to enable LDAP sign-in for themselves, they sho
GitLab has multiple mechanisms to verify a user is still active in LDAP. If the user is no longer active in
LDAP, they are placed in an `ldap_blocked` status and are signed out. They are unable to sign in using any authentication provider until they are
-reactivated in LDAP.
+reactivated in LDAP.
Users are considered inactive in LDAP when they:
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index 0f5f60fcd8e45..a7a6c5056b209 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -68,7 +68,7 @@ a single URL used by all Geo sites, including the primary.
In the Geo administration page of the **primary** site, edit each Geo secondary that
is using the secondary proxying and set the `URL` field to the single URL.
Make sure the primary site is also using this URL.
-
+
## Disable Geo proxying
You can disable the secondary proxying on each Geo site, separately, by following these steps with Omnibus-based packages:
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 942bc0af8dd49..12dd7e459bff5 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -551,7 +551,7 @@ Plan.default.actual_limits.update!(pages_file_entries: 100)
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321368) in GitLab 13.12. Disabled by default.
> - Enabled on GitLab.com in GitLab 14.3.
> - Enabled on self-managed in GitLab 14.4.
-> - Feature flag `ci_runner_limits` removed in GitLab 14.4.
+> - Feature flag `ci_runner_limits` removed in GitLab 14.4.
> - Feature flag `ci_runner_limits_override` removed in GitLab 14.6.
The total number of registered runners is limited at the group and project levels. Each time a new runner is registered,
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index a85f678fe95b4..f33d494f63854 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -101,10 +101,10 @@ To look up a project's hash path using a Rails console:
#### From hashed path to project name
-Administrators can look up a project's name from its hashed storage path using:
+Administrators can look up a project's name from its hashed storage path using:
- A Rails console.
-- The `config` file in the `*.git` directory.
+- The `config` file in the `*.git` directory.
To look up a project's name using the Rails console:
diff --git a/doc/api/members.md b/doc/api/members.md
index 51f7b74f110d4..2e2b403eea1ff 100644
--- a/doc/api/members.md
+++ b/doc/api/members.md
@@ -596,9 +596,9 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/:id/members/:user_id"
```
-## Approve a member for a group
+## Approve a member for a group
-Approves a pending user for a group and its subgroups and projects.
+Approves a pending user for a group and its subgroups and projects.
```plaintext
PUT /groups/:id/members/:user_id/approve
@@ -615,7 +615,7 @@ Example request:
curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/:id/members/:user_id/approve"
```
-## Approve all pending members for a group
+## Approve all pending members for a group
Approves all pending users for a group and its subgroups and projects.
diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md
index dc5faf0188eef..2a002b8fb9f60 100644
--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
@@ -59,7 +59,7 @@ To make submodules work correctly in CI/CD jobs:
variables:
GIT_SUBMODULE_STRATEGY: recursive
```
-
+
If you use the [`CI_JOB_TOKEN`](jobs/ci_job_token.md) to clone a submodule in a
pipeline job, the user executing the job must be assigned to a role that has
[permission](../user/permissions.md#gitlab-cicd-permissions) to trigger a pipeline
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index be267ec1da150..f9e4f3fbdea41 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -39,7 +39,7 @@ If the pipeline for the merge request at the front of the train completes succes
the changes are merged into the target branch, and the other pipelines continue to
run.
-To add a merge request to a merge train, you need [permissions](../../user/permissions.md) to merge or push to the
+To add a merge request to a merge train, you need [permissions](../../user/permissions.md) to merge or push to the
target branch.
Each merge train can run a maximum of **twenty** pipelines in parallel.
diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index 571d2f353d404..0e8e828946466 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -317,11 +317,11 @@ end
You must test the database index changes locally before creating a merge request.
-### Verify indexes created asynchronously
+### Verify indexes created asynchronously
Use the asynchronous index helpers on your local environment to test changes for creating an index:
1. Enable the feature flags by running `Feature.enable(:database_async_index_creation)` and `Feature.enable(:database_reindexing)` in the Rails console.
1. Run `bundle exec rails db:migrate` so that it creates an entry in the `postgres_async_indexes` table.
1. Run `bundle exec rails gitlab:db:reindex` so that the index is created asynchronously.
-1. To verify the index, open the PostgreSQL console using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/postgresql.md) command `gdk psql` and run the command `\d <index_name>` to check that your newly created index exists.
+1. To verify the index, open the PostgreSQL console using the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/postgresql.md) command `gdk psql` and run the command `\d <index_name>` to check that your newly created index exists.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 82fd62d8d796e..cc6997e1a2050 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -100,7 +100,7 @@ request is as follows:
There isn't a way to know anything about our customers' data on their
[self-managed instances](../../subscriptions/self_managed/index.md), so keep
that in mind for any data implications with your merge request.
-
+
1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
1. For tests that use Capybara, read
[how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 5d5d37e039866..ab808e6f1b7fb 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -73,7 +73,7 @@ component, is that you avoid the need to create a fixture or an HTML element in
##### provide/inject
Vue supports dependency injection through [provide/inject](https://vuejs.org/v2/api/#provide-inject).
-In the component the `inject` configuration accesses the values `provide` passes down.
+In the component the `inject` configuration accesses the values `provide` passes down.
This example of a Vue app initialization shows how the `provide` configuration passes a value from HAML to the component:
```javascript
diff --git a/doc/development/fe_guide/vue3_migration.md b/doc/development/fe_guide/vue3_migration.md
index c6f480deb223f..2b783eb21b780 100644
--- a/doc/development/fe_guide/vue3_migration.md
+++ b/doc/development/fe_guide/vue3_migration.md
@@ -31,7 +31,7 @@ Component's computed properties / methods or external helpers.
**When to use**
-If you are in a Vue app that doesn't use any event hub, try to avoid adding a new one unless absolutely necessary. For example, if you need a child component to react to its parent's event, it's preferred to pass a prop down. Then, use the watch property on that prop in the child component to create the desired side effect.
+If you are in a Vue app that doesn't use any event hub, try to avoid adding a new one unless absolutely necessary. For example, if you need a child component to react to its parent's event, it's preferred to pass a prop down. Then, use the watch property on that prop in the child component to create the desired side effect.
If you need cross-component communication (between different Vue apps), then perhaps introducing a hub is the right decision.
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index b38696263b406..c32789740c3a0 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -27,7 +27,7 @@ To implement a new metric in Service Ping, follow these steps:
1. [Set up and test Service Ping locally](#set-up-and-test-service-ping-locally)
NOTE:
-When you add or change a Service Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md).
+When you add or change a Service Metric, you must migrate metrics to [instrumentation classes](metrics_instrumentation.md).
For information about the progress on migrating Service ping metrics, see this [epic](https://gitlab.com/groups/gitlab-org/-/epics/5547).
## Instrumentation classes
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 0b8bc42276c06..1f751eea4d839 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -21,7 +21,7 @@ and sales teams understand how GitLab is used. The data helps to:
Service Ping information is not anonymous. It's linked to the instance's hostname, but does
not contain project names, usernames, or any other specific data.
-Sending a Service Ping payload is optional and you can [disable](#disable-service-ping) it on any
+Sending a Service Ping payload is optional and you can [disable](#disable-service-ping) it on any
self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances
and can show your instance's usage statistics to your users.
@@ -41,10 +41,10 @@ We use the following terminology to describe the Service Ping components:
The main purpose of Service Ping is to build a better GitLab. We collect data about how GitLab is used
to understand feature or stage adoption and usage. This data gives an insight into how GitLab adds
-value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to
+value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to
make better product decisions.
-There are several other benefits to enabling Service Ping:
+There are several other benefits to enabling Service Ping:
- As a benefit of having Service Ping active, GitLab lets you analyze the users' activities over time of your GitLab installation.
- As a benefit of having Service Ping active, GitLab provides you with [DevOps Score](../../user/admin_area/analytics/dev_ops_report.md#devops-score), which gives you an overview of your entire instance's adoption of Concurrent DevOps from planning to monitoring.
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index f4fe80ad15ee0..a643b89b7ff32 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -354,7 +354,7 @@ This way we are always comparing the latest binary replication pointer,
making sure that we read from the replica that is fully caught up.
FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to
[disable the feature flag](../administration/feature_flags.md) named preserve_latest_wal_locations_for_idempotent_jobs flag.
This feature flag is related to GitLab development and is not intended to be used by GitLab administrators, though.
diff --git a/doc/development/snowplow/implementation.md b/doc/development/snowplow/implementation.md
index fe1de789eae05..3ffacc5af6735 100644
--- a/doc/development/snowplow/implementation.md
+++ b/doc/development/snowplow/implementation.md
@@ -13,12 +13,12 @@ This page describes how to:
## Snowplow JavaScript frontend tracking
-GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
-to track custom events.
+GitLab provides a `Tracking` interface that wraps the [Snowplow JavaScript tracker](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/)
+to track custom events.
For the recommended frontend tracking implementation, see [Usage recommendations](#usage-recommendations).
-Tracking implementations must have an `action` and a `category`. You can provide additional
+Tracking implementations must have an `action` and a `category`. You can provide additional
categories from the [structured event taxonomy](index.md#structured-event-taxonomy) with an `extra` object
that accepts key-value pairs.
@@ -67,8 +67,8 @@ The following example shows `data-track-*` attributes assigned to a button:
#### Event listeners
Event listeners bind at the document level to handle click events in elements with data attributes.
-This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces
-the likelihood that click events stop propagating up the DOM tree.
+This allows them to be handled when the DOM re-renders or changes. Document-level binding reduces
+the likelihood that click events stop propagating up the DOM tree.
If click events stop propagating, you must implement listeners and [Vue component tracking](#implement-vue-component-tracking) or [raw JavaScript tracking](#implement-raw-javascript-tracking).
@@ -102,12 +102,12 @@ track_action: "click_button" })
### Implement Vue component tracking
For custom event tracking, use a Vue `mixin` in components. Vue `mixin` exposes the `Tracking.event`
-static method and the `track` method. You can specify tracking options in `data` or `computed`.
-These options override any defaults and allow the values to be dynamic from props or based on state.
+static method and the `track` method. You can specify tracking options in `data` or `computed`.
+These options override any defaults and allow the values to be dynamic from props or based on state.
-Several default options are passed when an event is tracked from the component:
+Several default options are passed when an event is tracked from the component:
-- `category`: If you don't specify, by default `document.body.dataset.page` is used.
+- `category`: If you don't specify, by default `document.body.dataset.page` is used.
- `label`
- `property`
- `value`
@@ -121,7 +121,7 @@ To implement Vue component tracking:
const trackingMixin = Tracking.mixin;
```
-1. Provide categories to track the event from the component. For example, to track all events in a
+1. Provide categories to track the event from the component. For example, to track all events in a
component with a label, use the `label` category:
```javascript
@@ -293,14 +293,14 @@ describe('MyTracking', () => {
### Form tracking
-To enable Snowplow automatic [form tracking](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
+To enable Snowplow automatic [form tracking](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/javascript-trackers/javascript-tracker/javascript-tracker-v2/tracking-specific-events/#form-tracking):
-1. Call `Tracking.enableFormTracking` when the DOM is ready.
+1. Call `Tracking.enableFormTracking` when the DOM is ready.
1. Provide a `config` object that includes at least one of the following elements:
- `forms` determines the forms to track. Identified by the CSS class name.
- `fields` determines the fields inside the tracked forms to track. Identified by the field `name`.
1. Optional. Provide a list of contexts as the second argument. The [`gitlab_standard`](schemas.md#gitlab_standard) schema is excluded from these events.
-
+
```javascript
Tracking.enableFormTracking({
forms: { allow: ['sign-in-form', 'password-recovery-form'] },
@@ -339,7 +339,7 @@ Backend tracking provides:
- User behavior tracking
- Instrumentation to monitor and visualize performance over time in a section or aspect of code.
-To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method.
+To add custom event tracking and instrumentation, call the `GitLab::Tracking.event` class method.
For example:
```ruby
@@ -370,7 +370,7 @@ Use the following arguments:
### Unit testing
-To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see
+To test backend Snowplow events, use the `expect_snowplow_event` helper. For more information, see
[testing best practices](../testing_guide/best_practices.md#test-snowplow-events).
### Performance
@@ -419,17 +419,17 @@ Snowplow Inspector Chrome Extension is a browser extension for testing frontend
[Snowplow Micro](https://snowplowanalytics.com/blog/2019/07/17/introducing-snowplow-micro/) is a
Docker-based solution for testing backend and frontend in a local development environment. Snowplow Micro
-records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.
+records the same events as the full Snowplow pipeline. To query events, use the Snowplow Micro API.
-To install and run Snowplow Micro, complete these steps to modify the
+To install and run Snowplow Micro, complete these steps to modify the
[GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit):
1. Ensure [Docker is installed](https://docs.docker.com/get-docker/) and running.
-1. To install Snowplow Micro, clone the settings in
+1. To install Snowplow Micro, clone the settings in
[this project](https://gitlab.com/gitlab-org/snowplow-micro-configuration).
-1. Navigate to the directory with the cloned project,
+1. Navigate to the directory with the cloned project,
and start the appropriate Docker container:
```shell
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index 757fb53ec2ec3..abd3b978f5d37 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -93,7 +93,7 @@ the indexer itself.
This project relies on [International Components for Unicode](https://icu.unicode.org/) (ICU) for text encoding,
therefore we must ensure the development packages for your platform are
-installed before running `make`.
+installed before running `make`.
#### Debian / Ubuntu
diff --git a/doc/integration/jira/dvcs.md b/doc/integration/jira/dvcs.md
index 8a1664dff79c2..e69b7675a590d 100644
--- a/doc/integration/jira/dvcs.md
+++ b/doc/integration/jira/dvcs.md
@@ -273,7 +273,7 @@ If you get a `Sync Failed` error in Jira when [refreshing repository data](#refr
```plaintext
Failed to execute request [https://gitlab.com/api/v4/projects/:id/merge_requests?page=1&per_page=100 GET https://gitlab.com/api/v4/projects/:id/merge_requests?page=1&per_page=100 returned a response status of 403 Forbidden] errors:
{"message":"403 Forbidden"}
-```
+```
If you find a `{"message":"403 Forbidden"}` error, it is possible that this specific project has some [GitLab features disabled](../../user/project/settings/index.md#sharing-and-permissions).
In the example above, the merge requests feature is disabled.
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index 5aa75aca8fc6d..47ef90cbe55dc 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -27,7 +27,7 @@ sent.
Webhook requests are made by the GitLab server itself and use a single
(optional) secret token per hook for authorization (instead of a user or
repository-specific token). As a result, these requests may have broader access than
-intended, including access to everything running on the server hosting the webhook. This
+intended, including access to everything running on the server hosting the webhook. This
may include the GitLab server or API itself (for example, `http://localhost:123`).
Depending on the called webhook, this may also result in network access
to other servers within that webhook server's local network (for example,
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index 404f1a7520425..e174a144cfcd9 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -323,7 +323,7 @@ To purchase additional minutes for your personal namespace:
1. Select **Edit profile**.
1. On the left sidebar, select **Usage Quotas**.
1. Select **Buy additional minutes** and GitLab redirects you to the Customers Portal.
-1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, click **Buy more CI minutes**, and complete the details about the transaction.
+1. Locate the subscription card that's linked to your personal namespace on GitLab SaaS, click **Buy more CI minutes**, and complete the details about the transaction.
After we process your payment, the extra CI minutes are synced to your group
namespace.
diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md
index 3947a72cac6ac..b58f5e6c5ebc3 100644
--- a/doc/topics/cron/index.md
+++ b/doc/topics/cron/index.md
@@ -66,6 +66,6 @@ More examples of how to write a cron schedule can be found at
GitLab uses [`fugit`](https://github.com/floraison/fugit) to parse cron syntax
strings on the server and [cron-validator](https://github.com/TheCloudConnectors/cron-validator)
-to validate cron syntax in the browser. GitLab uses
+to validate cron syntax in the browser. GitLab uses
[`cRonstrue`](https://github.com/bradymholt/cRonstrue) to convert cron to human-readable strings
in the browser.
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 7a7b7cfe1a803..aafaabad81f48 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -242,7 +242,7 @@ Announced: 2021-11-22
### Value Stream Analytics filtering calculation change
-We are changing how the date filter works in Value Stream Analytics. Instead of filtering by the time that the issue or merge request was created, the date filter will filter by the end event time of the given stage. This will result in completely different figures after this change has rolled out.
+We are changing how the date filter works in Value Stream Analytics. Instead of filtering by the time that the issue or merge request was created, the date filter will filter by the end event time of the given stage. This will result in completely different figures after this change has rolled out.
If you monitor Value Stream Analytics metrics and rely on the date filter, to avoid losing data, you must save the data prior to this change.
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 35d5d56761dd9..d25caf1d7b4a6 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -258,7 +258,7 @@ To [Create a new group](../group/index.md#create-a-group) click **New group**.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340920) in GitLab 14.4.
-You can administer all [topics](../project/working_with_projects.md#explore-topics) in the
+You can administer all [topics](../project/working_with_projects.md#explore-topics) in the
GitLab instance from the Admin Area's Topics page.
To access the Topics page:
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 0cc21e3f390cd..6a157dbb5ae40 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -100,29 +100,29 @@ We use the following terms to describe GitLab analytics:
- All incidents are related to a [production environment](../../ci/environments/index.md#deployment-tier-of-environments).
- Incidents and deployments have a strictly one-to-one relationship (meaning any incident is related to only one production deployment, and any production deployment is related to no more than one incident).
-- **Lead time:** The duration of your value stream, from start to finish. Different to
-[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time,"
-which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead
+- **Lead time:** The duration of your value stream, from start to finish. Different to
+[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time,"
+which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead
time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md).
-- **Mean Time to Change (MTTC):** The average duration between idea and delivery. GitLab measures
+- **Mean Time to Change (MTTC):** The average duration between idea and delivery. GitLab measures
MTTC from issue creation to the issue's latest related merge request's deployment to production.
-- **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production.
+- **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production.
GitLab measures MTTD from deployment of bug to issue creation.
-- **Mean Time To Merge (MTTM):** The average lifespan of a merge request. GitLab measures MTTM from
-merge request creation to merge request merge (and closed/un-merged merge requests are excluded).
+- **Mean Time To Merge (MTTM):** The average lifespan of a merge request. GitLab measures MTTM from
+merge request creation to merge request merge (and closed/un-merged merge requests are excluded).
For more information, see [Merge Request Analytics](merge_request_analytics.md).
-- **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug
+- **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug
is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix.
-- **Throughput:** The number of issues closed or merge requests merged (not closed) in a period of
+- **Throughput:** The number of issues closed or merge requests merged (not closed) in a period of
time. Often measured per sprint. GitLab displays merge request throughput in [Merge Request Analytics](merge_request_analytics.md).
-- **Value Stream:** The entire work process that is followed to deliver value to customers. For example,
-the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
+- **Value Stream:** The entire work process that is followed to deliver value to customers. For example,
+the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
with "plan" and ends with "monitor". GitLab helps you track your value stream using [Value Stream Analytics](value_stream_analytics.md).
-- **Velocity:** The total issue burden completed in some period of time. The burden is usually measured
-in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab
+- **Velocity:** The total issue burden completed in some period of time. The burden is usually measured
+in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab
measures velocity as the total points or weight of issues closed in a given period of time.
## Lead time for changes
-"Lead Time for Changes" differs from "Lead Time" because it "focuses on measuring only the time to
+"Lead Time for Changes" differs from "Lead Time" because it "focuses on measuring only the time to
deliver a feature once it has been developed", as described in ([Measuring DevOps Performance](https://devops.com/measuring-devops-performance/)).
diff --git a/doc/user/analytics/productivity_analytics.md b/doc/user/analytics/productivity_analytics.md
index da55a0f093cf5..e1ba2f5565e97 100644
--- a/doc/user/analytics/productivity_analytics.md
+++ b/doc/user/analytics/productivity_analytics.md
@@ -34,14 +34,14 @@ Metrics and visualizations of **merged** merge requests are available on a proje
### Time to merge
-The **Time to merge** histogram shows the number of merge requests and the number
+The **Time to merge** histogram shows the number of merge requests and the number
of days it took to merge after creation. Select a column to filter subsequent charts.
### Trendline
-The **Trendline** scatterplot shows all merge requests on a certain date,
+The **Trendline** scatterplot shows all merge requests on a certain date,
and the days it took to complete the action and a 30 day rolling median. Select the dropdown to view:
- Time from first commit to first comment.
@@ -55,15 +55,15 @@ and the days it took to complete the action and a 30 day rolling median. Select
### Commits and merge request size
-Under the **Trendline** scatterplot, the left-side histogram shows
-the time taken (in hours) between commits and comments until the merge
+Under the **Trendline** scatterplot, the left-side histogram shows
+the time taken (in hours) between commits and comments until the merge
request is merged. Select the dropdown to view:
- Time from first commit to first comment.
- Time from first comment until last commit.
- Time from last commit to merge.
-The right-side histogram shows the size or complexity of a merge request.
+The right-side histogram shows the size or complexity of a merge request.
Select the dropdown to view:
- Number of commits per merge request.
@@ -74,7 +74,7 @@ Select the dropdown to view:
### Merge request list
-The **List** table shows a list of merge requests with their respective time duration metrics.
+The **List** table shows a list of merge requests with their respective time duration metrics.
Sort metrics by:
@@ -83,7 +83,7 @@ Sort metrics by:
- Time from last commit to merge.
Filter metrics by:
-
+
- Number of commits per merge request.
- Number of lines of code per commit.
- Number of files touched.
diff --git a/doc/user/application_security/api_fuzzing/index.md b/doc/user/application_security/api_fuzzing/index.md
index 9ba24d9931f16..d96d28d3c667f 100644
--- a/doc/user/application_security/api_fuzzing/index.md
+++ b/doc/user/application_security/api_fuzzing/index.md
@@ -14,7 +14,7 @@ miss.
INFO:
Try fuzz testing in GitLab Ultimate.
-[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-api-fuzzing-docs).
+[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-api-fuzzing-docs).
We recommend that you use fuzz testing in addition to [GitLab Secure](../index.md)'s
other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/index.md),
diff --git a/doc/user/application_security/dast/browser_based.md b/doc/user/application_security/dast/browser_based.md
index 7e3d927f31d00..f63ed2a5079ba 100644
--- a/doc/user/application_security/dast/browser_based.md
+++ b/doc/user/application_security/dast/browser_based.md
@@ -69,7 +69,7 @@ The browser-based crawler can be configured using CI/CD variables.
| `DAST_BROWSER_SEARCH_ELEMENT_TIMEOUT` | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `3s` | The maximum amount of time to allow the browser to search for new elements or navigations. |
| `DAST_BROWSER_EXTRACT_ELEMENT_TIMEOUT` | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `5s` | The maximum amount of time to allow the browser to extract newly found elements or navigations. |
| `DAST_BROWSER_ELEMENT_TIMEOUT` | [Duration string](https://golang.org/pkg/time/#ParseDuration) | `600ms` | The maximum amount of time to wait for an element before determining it is ready for analysis. |
-| `DAST_BROWSER_PAGE_READY_SELECTOR` | selector | `css:#page-is-ready` | Selector that when detected as visible on the page, indicates to the analyzer that the page has finished loading and the scan can continue. Note: When this selector is set, but the element is not found, the scanner waits for the period defined in `DAST_BROWSER_STABILITY_TIMEOUT` before continuing the scan. This can significantly increase scanning time if the element is not present on multiple pages within the site. |
+| `DAST_BROWSER_PAGE_READY_SELECTOR` | selector | `css:#page-is-ready` | Selector that when detected as visible on the page, indicates to the analyzer that the page has finished loading and the scan can continue. Note: When this selector is set, but the element is not found, the scanner waits for the period defined in `DAST_BROWSER_STABILITY_TIMEOUT` before continuing the scan. This can significantly increase scanning time if the element is not present on multiple pages within the site. |
The [DAST variables](index.md#available-cicd-variables) `SECURE_ANALYZERS_PREFIX`, `DAST_FULL_SCAN_ENABLED`, `DAST_AUTO_UPDATE_ADDONS`, `DAST_EXCLUDE_RULES`, `DAST_REQUEST_HEADERS`, `DAST_HTML_REPORT`, `DAST_MARKDOWN_REPORT`, `DAST_XML_REPORT`,
`DAST_AUTH_URL`, `DAST_USERNAME`, `DAST_PASSWORD`, `DAST_USERNAME_FIELD`, `DAST_PASSWORD_FIELD`, `DAST_FIRST_SUBMIT_FIELD`, `DAST_SUBMIT_FIELD`, `DAST_EXCLUDE_URLS`, `DAST_AUTH_VERIFICATION_URL`, `DAST_BROWSER_AUTH_VERIFICATION_SELECTOR`, `DAST_BROWSER_AUTH_VERIFICATION_LOGIN_FORM`, `DAST_BROWSER_AUTH_REPORT`,
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index bfe0d8c2b9eed..8f26bc8a46ca0 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -18,7 +18,7 @@ tool [OWASP Zed Attack Proxy](https://www.zaproxy.org/) for analysis.
INFO:
Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-dast-docs).
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-dast-docs).
After DAST creates its report, GitLab evaluates it for discovered
vulnerabilities between the source and target branches. Relevant
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index d2029be7f3dd5..20d7b1931a0f4 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -18,7 +18,7 @@ actionable information _before_ changes are merged enables you to be proactive.
INFO:
Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-application-security-docs).
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-application-security-docs).
GitLab also provides high-level statistics of vulnerabilities across projects and groups:
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 18635599dda7a..122d462ac961c 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
INFO:
Want to try out security scanning?
-[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-security-dashboard-docs).
+[Try GitLab Ultimate free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-security-dashboard-docs).
GitLab provides a comprehensive set of features for viewing and managing vulnerabilities:
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index 3f639322c8f17..bbd8ebaf54c2f 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -19,7 +19,7 @@ The Agent is installed into the cluster through code, providing you with a fast,
INFO:
Get Network Security Alerts in GitLab by upgrading to Ultimate.
-[Try a free 30-day trial now](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=p-cluster-agent-docs).
+[Try a free 30-day trial now](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=p-cluster-agent-docs).
With GitOps, you can manage containerized clusters and applications from a Git repository that:
diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md
index fad9d4f08f1a0..83031c30e59af 100644
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@@ -353,7 +353,7 @@ Additional management interfaces are planned for the GitLab Kubernetes Agent.
## Upgrades and version compatibility
-The GitLab Kubernetes Agent is comprised of two major components: `agentk` and `kas`.
+The GitLab Kubernetes Agent is comprised of two major components: `agentk` and `kas`.
As we provide `kas` installers built into the various GitLab installation methods, the required `kas` version corresponds to the GitLab `major.minor` (X.Y) versions.
At the same time, `agentk` and `kas` can differ by 1 minor version in either direction. For example,
diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md
index 7b8c2d5cff8b6..f92c2cd9a05a6 100644
--- a/doc/user/compliance/license_compliance/index.md
+++ b/doc/user/compliance/license_compliance/index.md
@@ -16,7 +16,7 @@ is incompatible with yours, then you can deny the use of that license.
INFO:
Try License Compliance scanning to search project dependencies in GitLab Ultimate.
-[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-compliance-docs).
+[It's free for 30 days](https://about.gitlab.com/free-trial?glm_source=docs.gitlab.com&glm_content=u-compliance-docs).
You can take advantage of License Compliance by either:
@@ -194,8 +194,8 @@ directory of your project.
### Working with Monorepos
-Depending on your language, you may need to specify the path to the individual
-projects of a monorepo using the `LICENSE_FINDER_CLI_OPTS` variable. Passing in
+Depending on your language, you may need to specify the path to the individual
+projects of a monorepo using the `LICENSE_FINDER_CLI_OPTS` variable. Passing in
the project paths can significantly speed up builds over using the `--recursive`
license_finder option.
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
index c67fa4abfc5eb..4151745189dcf 100644
--- a/doc/user/group/devops_adoption/index.md
+++ b/doc/user/group/devops_adoption/index.md
@@ -22,7 +22,7 @@ You can use Group DevOps Adoption to:
- Identify specific subgroups that are lagging in their adoption of GitLab features, so you can guide them on
their DevOps journey.
-- Find subgroups that have adopted certain features, and provide guidance to other subgroups on
+- Find subgroups that have adopted certain features, and provide guidance to other subgroups on
how to use those features.
- Verify if you are getting the return on investment that you expected from GitLab.
@@ -51,7 +51,7 @@ DevOps Adoption shows feature adoption for development, security, and operations
## Feature adoption
-DevOps Adoption shows feature adoption data for groups and subgroups for the previous calendar month.
+DevOps Adoption shows feature adoption data for groups and subgroups for the previous calendar month.
A feature shows as **adopted** when a group has used the feature in a project during the time period.
This includes projects in any subgroups of the group. For example, if an issue was created in a project in a group, the group has adopted issues in that time.
@@ -63,12 +63,12 @@ When GitLab measures DevOps Adoption, some common DevOps information is not incl
- Dormant projects. It doesn't matter how many projects in the group use a feature. Even if you have many dormant projects, it doesn't lower the adoption.
- New GitLab features. Adoption is the total number of features adopted, not the percent of features.
-## When DevOps Adoption data is gathered
+## When DevOps Adoption data is gathered
-A weekly task processes data for DevOps Adoption. This task is disabled until you access
-DevOps Adoption for a group for the first time.
+A weekly task processes data for DevOps Adoption. This task is disabled until you access
+DevOps Adoption for a group for the first time.
-The data processing task updates the data on the first day of each month. If the monthly update
+The data processing task updates the data on the first day of each month. If the monthly update
fails, the task tries daily until it succeeds.
DevOps Adoption data may take up to a minute to appear while GitLab processes the group's data.
@@ -76,13 +76,13 @@ DevOps Adoption data may take up to a minute to appear while GitLab processes th
## View feature adoption over time
The **Adoption over time** chart shows the total number of adopted features from the previous
-twelve months. The chart only shows data from when you enabled DevOps Adoption for the group.
+twelve months. The chart only shows data from when you enabled DevOps Adoption for the group.
To view feature adoption over time:
1. On the top bar, select **Menu > Groups** and find your group.
1. On the left sidebar, select **Analytics > DevOps adoption**.
-1. Select the **Overview** tab.
+1. Select the **Overview** tab.
Tooltips display information about the features tracked for individual months.
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 42fc2f532e1db..a586ef9ffe8ba 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -568,7 +568,7 @@ You should consider these security implications before configuring IP address re
the IP restrictions. But when the running CI/CD job sends Git requests from a
restricted IP address, the IP restriction prevents code from being cloned.
- **User dashboard activity**: Users may still see some events from the IP restricted groups and projects
- on their dashboard. Activity may include push, merge, issue, or comment events.
+ on their dashboard. Activity may include push, merge, issue, or comment events.
To restrict group access by IP address:
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 6b3e72230a09b..e2a20c1c42758 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -126,7 +126,7 @@ SSO has the following effects when enabled:
- For groups, users can't share a project in the group outside the top-level group,
even if the project is forked.
- For Git activity over SSH and HTTPS, users must have at least one active session signed-in through SSO before they can push to or
- pull from a GitLab repository.
+ pull from a GitLab repository.
- Credentials that are not tied to regular users (for example, access tokens and deploy keys) do not have the SSO check enforced.
- Users must be signed-in through SSO before they can pull images using the [Dependency Proxy](../../packages/dependency_proxy/index.md).
<!-- Add bullet for API activity when https://gitlab.com/gitlab-org/gitlab/-/issues/9152 is complete -->
@@ -369,7 +369,7 @@ To link the SAML groups from the `saml:AttributeStatement` example above:
If a user is a member of multiple SAML groups mapped to the same GitLab group,
the user gets the highest access level from the groups. For example, if one group
is linked as `Guest` and another `Maintainer`, a user in both groups gets `Maintainer`
-access.
+access.
Users granted:
@@ -487,7 +487,7 @@ Specific attention should be paid to:
#### Generate a SAML Response
-SAML Responses can be used to preview the attribute names and values sent in the assertions list while attempting to sign in using an IdP.
+SAML Responses can be used to preview the attribute names and values sent in the assertions list while attempting to sign in using an IdP.
To generate a SAML Response:
diff --git a/doc/user/group/value_stream_analytics/index.md b/doc/user/group/value_stream_analytics/index.md
index a0a13c71d95ac..b91e258b04aac 100644
--- a/doc/user/group/value_stream_analytics/index.md
+++ b/doc/user/group/value_stream_analytics/index.md
@@ -86,8 +86,8 @@ the date filter behavior to filter the end event time of the currently selected
The change makes it possible to get a much better picture about the completed items within the
stage and helps uncover long-running items.
-For example, an issue was created a year ago and the current stage was finished in the current month.
-If you were to look at the metrics for the last three months, this issue would not be included in the calculation of
+For example, an issue was created a year ago and the current stage was finished in the current month.
+If you were to look at the metrics for the last three months, this issue would not be included in the calculation of
the stage metrics. With the new date filter, this item would be included.
DISCLAIMER:
@@ -100,7 +100,7 @@ sole discretion of GitLab Inc.
## How metrics are measured
-> DORA API-based deployment metrics for group-level Value Stream Analytics were
+> DORA API-based deployment metrics for group-level Value Stream Analytics were
> [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/337256) from GitLab Ultimate to GitLab Premium in 14.3.
The "Time" metrics near the top of the page are measured as follows:
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index a2d9ac21a1876..90cb6502bbd41 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -260,7 +260,7 @@ To change your commit email:
1. In the **Commit email** dropdown list, select an email address.
1. Select **Update profile settings**.
-## Change your primary email
+## Change your primary email
Your primary email:
diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md
index 94fe6ffac567a..27767f8d32558 100644
--- a/doc/user/project/repository/gpg_signed_commits/index.md
+++ b/doc/user/project/repository/gpg_signed_commits/index.md
@@ -40,7 +40,7 @@ For a commit to be verified by GitLab:
account.
- One of the emails in the GPG key must match a **verified** email address
used by the committer in GitLab. This address will be part of the public key.
- If you want to keep this address private, use the automatically generated
+ If you want to keep this address private, use the automatically generated
[private commit email address](../../../profile/index.md#use-an-automatically-generated-private-commit-email)
GitLab provides in your profile.
- The committer's email address must match the verified email address from the
--
GitLab