diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-12-03 18:10:36 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-12-03 18:10:36 +0300 |
commit | 78aaabb87f180e93fa53aba407a0eef1e12a7a56 (patch) | |
tree | 6072c319e481f75960853c557578a5d04315b1fe /doc | |
parent | 5f0d27d131aced1a53e8cbc7db023d9f947f8a1a (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
56 files changed, 124 insertions, 123 deletions
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md index 11790e3a58e..7c597bd5f0f 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 d2a783972dc..f551c362784 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/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md index 1b22a5f0991..c65cbb0b3ad 100644 --- a/doc/administration/geo/replication/version_specific_updates.md +++ b/doc/administration/geo/replication/version_specific_updates.md @@ -50,7 +50,7 @@ If you are running a version prior to 14.1 and are using Geo and multi-arch cont ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 14.0/14.1 @@ -64,7 +64,7 @@ If you are running an affected version and need to remove your Primary site, you ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 13.12 @@ -90,7 +90,7 @@ Geo::LfsObjectRegistry.where(state: 0, success: true).update_all(state: 2) ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 13.11 @@ -98,20 +98,20 @@ We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitla ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 13.10 ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 13.9 ### Error during zero-downtime update: "cannot drop column asset_proxy_whitelist" We've detected an issue [with a column rename](https://gitlab.com/gitlab-org/gitlab/-/issues/324160) -that will prevent upgrades to GitLab 13.9.0, 13.9.1, 13.9.2 and 13.9.3 when following the zero-downtime steps. It is necessary +that prevents upgrades to GitLab 13.9.0, 13.9.1, 13.9.2 and 13.9.3 when following the zero-downtime steps. It is necessary to perform the following additional steps for the zero-downtime update: 1. Before running the final `sudo gitlab-rake db:migrate` command on the deploy node, @@ -132,7 +132,7 @@ to perform the following additional steps for the zero-downtime update: ``` If you have already run the final `sudo gitlab-rake db:migrate` command on the deploy node and have -encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you will +encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you might see the following error: ```shell @@ -148,7 +148,7 @@ More details are available [in this issue](https://gitlab.com/gitlab-org/gitlab/ ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode -GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) will cause Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). +GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop updating and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode). ## Updating to GitLab 13.7 @@ -168,7 +168,7 @@ on Geo secondaries. This issue is fixed in GitLab 13.6.1 and later. In GitLab 13.3, Geo removed the PostgreSQL [Foreign Data Wrapper](https://www.postgresql.org/docs/11/postgres-fdw.html) dependency for the tracking database. -The FDW server, user, and the extension will be removed during the upgrade +The FDW server, user, and the extension is removed during the upgrade process on each secondary node. The GitLab settings related to the FDW in the `/etc/gitlab/gitlab.rb` have been deprecated and can be safely removed. diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md index 0f5f60fcd8e..a7a6c5056b2 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 942bc0af8dd..12dd7e459bf 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/package_information/deprecation_policy.md b/doc/administration/package_information/deprecation_policy.md index d45c2ea3127..164c0eb5c07 100644 --- a/doc/administration/package_information/deprecation_policy.md +++ b/doc/administration/package_information/deprecation_policy.md @@ -16,18 +16,18 @@ setup, various configuration requires removal. ### Policy -The Omnibus GitLab package will retain configuration for at least **one major** -version. We cannot guarantee that deprecated configuration -will be available in the next major release. See [example](#example) for more details. +The Omnibus GitLab package retains configuration for at least **one major** +version. We can't guarantee that deprecated configuration +is available in the next major release. See [example](#example) for more details. ### Notice -If the configuration becomes obsolete, we will announce the deprecation: +If the configuration becomes obsolete, we announce the deprecation: - via release blog post on `https://about.gitlab.com/blog/`. The blog post item - will contain the deprecation notice together with the target removal date. + contains the deprecation notice together with the target removal date. - via installation/reconfigure output (if applicable). -- via official documentation on `https://docs.gitlab.com/`. The documentation update will contain the corrected syntax (if applicable) or a date of configuration removal. +- via official documentation on `https://docs.gitlab.com/`. The documentation update contains the corrected syntax (if applicable) or a date of configuration removal. ### Procedure @@ -82,16 +82,16 @@ The final comment in the issue **has to have**: ## Example -User configuration available in `/etc/gitlab/gitlab.rb` was introduced in GitLab version 10.0, `gitlab_rails['configuration'] = true`. In GitLab version 10.4.0, a new change was introduced that requires rename of this configuration option. New configuration option is `gitlab_rails['better_configuration'] = true`. Development team will translate the old configuration into new one -and trigger a deprecation procedure. +User configuration available in `/etc/gitlab/gitlab.rb` was introduced in GitLab version 10.0, `gitlab_rails['configuration'] = true`. In GitLab version 10.4.0, a new change was introduced that requires rename of this configuration option. New configuration option is `gitlab_rails['better_configuration'] = true`. Development team translates the old configuration into a new one +and triggers a deprecation procedure. This means that these two configuration -options will both be valid through GitLab version 10. In other words, +options are valid through GitLab version 10. In other words, if you still have `gitlab_rails['configuration'] = true` set in GitLab 10.8.0 -the feature will continue working the same way as if you had `gitlab_rails['better_configuration'] = true` set. -However, setting the old version of configuration will print out a deprecation +the feature continues working the same way as if you had `gitlab_rails['better_configuration'] = true` set. +However, setting the old version of the configuration prints out a deprecation notice at the end of installation/upgrade/reconfigure run. -With GitLab 11, `gitlab_rails['configuration'] = true` will no longer work and you will have to manually change the configuration in `/etc/gitlab/gitlab.rb` to the new valid configuration. +In GitLab 11, `gitlab_rails['configuration'] = true` no longer works and you must manually change the configuration in `/etc/gitlab/gitlab.rb` to the new valid configuration. **Note** If this configuration option is sensitive and can put integrity of the installation or -data in danger, installation/upgrade will be aborted. +data in danger,the installation or upgrade is aborted. diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index a85f678fe95..f33d494f638 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/graphql/reference/index.md b/doc/api/graphql/reference/index.md index 36b56054c8d..b4f69b379ee 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -8687,7 +8687,7 @@ Represents the total number of issues and their weights for a particular day. | <a id="cijobneeds"></a>`needs` | [`CiBuildNeedConnection`](#cibuildneedconnection) | References to builds that must complete before the jobs run. (see [Connections](#connections)) | | <a id="cijobpipeline"></a>`pipeline` | [`Pipeline`](#pipeline) | Pipeline the job belongs to. | | <a id="cijobplayable"></a>`playable` | [`Boolean!`](#boolean) | Indicates the job can be played. | -| <a id="cijobpreviousstagejobsandneeds"></a>`previousStageJobsAndNeeds` | [`CiJobConnection`](#cijobconnection) | All prerequisite jobs. (see [Connections](#connections)) | +| <a id="cijobpreviousstagejobsorneeds"></a>`previousStageJobsOrNeeds` | [`CiJobConnection`](#cijobconnection) | Jobs that must complete before the job runs. Returns needed jobs if the job uses the `needs` keyword, and returns previous stage jobs otherwise. (see [Connections](#connections)) | | <a id="cijobqueuedat"></a>`queuedAt` | [`Time`](#time) | When the job was enqueued and marked as pending. | | <a id="cijobqueuedduration"></a>`queuedDuration` | [`Duration`](#duration) | How long the job was enqueued before starting. | | <a id="cijobrefname"></a>`refName` | [`String`](#string) | Ref name of the job. | diff --git a/doc/api/members.md b/doc/api/members.md index 51f7b74f110..2e2b403eea1 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/api/projects.md b/doc/api/projects.md index 19a4b3d3224..9d7566f6967 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -1072,7 +1072,7 @@ If the project is a fork, and you provide a valid token to authenticate, the "ssh_url_to_repo":"git@gitlab.com:gitlab-org/gitlab-foss.git", "http_url_to_repo":"https://gitlab.com/gitlab-org/gitlab-foss.git", "web_url":"https://gitlab.com/gitlab-org/gitlab-foss", - "avatar_url":"https://assets.gitlab-static.net/uploads/-/system/project/avatar/13083/logo-extra-whitespace.png", + "avatar_url":"https://gitlab.com/uploads/-/system/project/avatar/13083/logo-extra-whitespace.png", "license_url": "https://gitlab.com/gitlab-org/gitlab/-/blob/master/LICENSE", "license": { "key": "mit", diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md index 5ea603e0b7c..57fd72863c1 100644 --- a/doc/ci/environments/protected_environments.md +++ b/doc/ci/environments/protected_environments.md @@ -79,7 +79,7 @@ Alternatively, you can use the API to protect an environment: $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \ --data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members" - {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://assets.gitlab-static.net/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null} + {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null} ``` 1. Use the API to add the group to the project as a reporter: diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md index dc5faf0188e..2a002b8fb9f 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 be267ec1da1..f9e4f3fbdea 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 571d2f353d4..0e8e8289464 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 82fd62d8d79..cc6997e1a20 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 5d5d37e0398..ab808e6f1b7 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 c6f480deb22..2b783eb21b7 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/image_scaling.md b/doc/development/image_scaling.md index 82ca8cf8e83..e1ffbdb766a 100644 --- a/doc/development/image_scaling.md +++ b/doc/development/image_scaling.md @@ -37,8 +37,8 @@ Furthermore, configuration in Workhorse can lead to the image scaler rejecting a For instance, here are two different URLs that serve the GitLab project avatar both in its original size and scaled down to 64 pixels. Only the second request will trigger the image scaler: -- [`/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png`](https://assets.gitlab-static.net/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png) -- [`/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png?width=64`](https://assets.gitlab-static.net/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png?width=64) +- [`/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png`](https://gitlab.com/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png) +- [`/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png?width=64`](https://gitlab.com/uploads/-/system/project/avatar/278964/logo-extra-whitespace.png?width=64) ## Where do we scale images? diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md index b38696263b4..c32789740c3 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 0b8bc42276c..1f751eea4d8 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 f4fe80ad15e..a643b89b7ff 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 fe1de789eae..3ffacc5af67 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/development/testing_guide/img/review-app-parent-pipeline.png b/doc/development/testing_guide/img/review-app-parent-pipeline.png Binary files differindex 5686d5f6ebe..dd64d7d1be5 100644 --- a/doc/development/testing_guide/img/review-app-parent-pipeline.png +++ b/doc/development/testing_guide/img/review-app-parent-pipeline.png diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 9705242ea35..89f36397039 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/img/ding_talk_menu.png b/doc/integration/img/ding_talk_menu.png Binary files differindex 2c5a23435fa..fe020cab397 100644 --- a/doc/integration/img/ding_talk_menu.png +++ b/doc/integration/img/ding_talk_menu.png diff --git a/doc/integration/img/omniauth_providers_v_14_6.png b/doc/integration/img/omniauth_providers_v_14_6.png Binary files differindex 9d67b47c4e2..b434e9a210b 100644 --- a/doc/integration/img/omniauth_providers_v_14_6.png +++ b/doc/integration/img/omniauth_providers_v_14_6.png diff --git a/doc/integration/jira/dvcs.md b/doc/integration/jira/dvcs.md index 8a1664dff79..e69b7675a59 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 5aa75aca8fc..47ef90cbe55 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 404f1a75204..e174a144cfc 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 3947a72cac6..b58f5e6c5eb 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 7a7b7cfe1a8..aafaabad81f 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 35d5d56761d..d25caf1d7b4 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/img/product_analytics_commits_per_mr_v14_4.png b/doc/user/analytics/img/product_analytics_commits_per_mr_v14_4.png Binary files differindex 649416c02c0..2bfde7beead 100644 --- a/doc/user/analytics/img/product_analytics_commits_per_mr_v14_4.png +++ b/doc/user/analytics/img/product_analytics_commits_per_mr_v14_4.png diff --git a/doc/user/analytics/img/productivity_analytics_time_to_merge_v14_4.png b/doc/user/analytics/img/productivity_analytics_time_to_merge_v14_4.png Binary files differindex b5d0dd4d2ea..0b30aff2c7a 100644 --- a/doc/user/analytics/img/productivity_analytics_time_to_merge_v14_4.png +++ b/doc/user/analytics/img/productivity_analytics_time_to_merge_v14_4.png diff --git a/doc/user/analytics/img/productivity_analytics_trendline_v14_4.png b/doc/user/analytics/img/productivity_analytics_trendline_v14_4.png Binary files differindex da5d3aec957..e0b3c54dee2 100644 --- a/doc/user/analytics/img/productivity_analytics_trendline_v14_4.png +++ b/doc/user/analytics/img/productivity_analytics_trendline_v14_4.png diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index 0cc21e3f390..6a157dbb5ae 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 da55a0f093c..e1ba2f5565e 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. ![Metrics for number of days merge requests per number of days](img/productivity_analytics_time_to_merge_v14_4.png) ### 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 9ba24d9931f..d96d28d3c66 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 7e3d927f31d..f63ed2a5079 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 bfe0d8c2b9e..8f26bc8a46c 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 d2029be7f3d..20d7b1931a0 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/img/pipeline_security_dashboard_v14_4.png b/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v14_4.png Binary files differindex ac123d2b528..ad9122ee23c 100644 --- a/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v14_4.png +++ b/doc/user/application_security/security_dashboard/img/pipeline_security_dashboard_v14_4.png diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md index 18635599dda..122d462ac96 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 3f639322c8f..bbd8ebaf54c 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 fad9d4f08f1..83031c30e59 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/img/policies_maintainer_edit_v14_3.png b/doc/user/compliance/license_compliance/img/policies_maintainer_edit_v14_3.png Binary files differindex 85b2a52e04b..256c66bf7d8 100644 --- a/doc/user/compliance/license_compliance/img/policies_maintainer_edit_v14_3.png +++ b/doc/user/compliance/license_compliance/img/policies_maintainer_edit_v14_3.png diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md index 7b8c2d5cff8..143e2badd9d 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: @@ -51,6 +51,7 @@ When GitLab detects a **Denied** license, you can view it in the [license list]( ![License List](img/license_list_v13_0.png) You can view and modify existing policies from the [policies](#policies) tab. + ![Edit Policy](img/policies_maintainer_edit_v14_3.png) ## License expressions @@ -194,8 +195,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 c67fa4abfc5..4151745189d 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 42fc2f532e1..a586ef9ffe8 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 6b3e72230a0..e2a20c1c427 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 a0a13c71d95..b91e258b04a 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/img/award_emoji_select_v14_6.png b/doc/user/img/award_emoji_select_v14_6.png Binary files differindex 500b78bdf44..c8185a1b4cb 100644 --- a/doc/user/img/award_emoji_select_v14_6.png +++ b/doc/user/img/award_emoji_select_v14_6.png diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md index a2d9ac21a18..90cb6502bbd 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/integrations/img/webhook_testing.png b/doc/user/project/integrations/img/webhook_testing.png Binary files differindex 27836556acc..88ce05668f9 100644 --- a/doc/user/project/integrations/img/webhook_testing.png +++ b/doc/user/project/integrations/img/webhook_testing.png diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md index 94fe6ffac56..27767f8d325 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 diff --git a/doc/user/project/repository/jupyter_notebooks/img/jupyter_notebook_diff_v14_5.png b/doc/user/project/repository/jupyter_notebooks/img/jupyter_notebook_diff_v14_5.png Binary files differindex bc63322cd65..3dc940c23de 100644 --- a/doc/user/project/repository/jupyter_notebooks/img/jupyter_notebook_diff_v14_5.png +++ b/doc/user/project/repository/jupyter_notebooks/img/jupyter_notebook_diff_v14_5.png |