diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-25 00:10:17 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-25 00:10:17 +0300 |
commit | ba0d8b409534f02c23bf2447fd32246926ba4392 (patch) | |
tree | 722b4f0f7be05189bfa5a0d06b20383b4680b5a1 /doc | |
parent | fd247970cfe1e98276c780fbdcca026b7960e42a (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
31 files changed, 78 insertions, 54 deletions
diff --git a/doc/administration/auth/index.md b/doc/administration/auth/index.md index 307d9a4518d..3c4b695fb67 100644 --- a/doc/administration/auth/index.md +++ b/doc/administration/auth/index.md @@ -29,7 +29,7 @@ For more information, see the links shown on this page for each external provide |-------------------------------------------------|-----------------------------------------|------------------------------------| | **User Provisioning** | SCIM<br>SAML <sup>1</sup> | LDAP <sup>1</sup><br>SAML <sup>1</sup><br>[OmniAuth Providers](../../integration/omniauth.md#supported-providers) <sup>1</sup> | | **User Detail Updating** (not group management) | Not Available | LDAP Sync | -| **Authentication** | SAML at top-level group (1 provider) | LDAP (multiple providers)<br>Generic OAuth2<br>SAML (only 1 permitted per unique provider)<br>Kerberos<br>JWT<br>Smartcard<br>[OmniAuth Providers](../../integration/omniauth.md#supported-providers) (only 1 permitted per unique provider) | +| **Authentication** | SAML at top-level group (1 provider) | LDAP (multiple providers)<br>Generic OAuth 2.0<br>SAML (only 1 permitted per unique provider)<br>Kerberos<br>JWT<br>Smartcard<br>[OmniAuth Providers](../../integration/omniauth.md#supported-providers) (only 1 permitted per unique provider) | | **Provider-to-GitLab Role Sync** | SAML Group Sync | LDAP Group Sync<br>SAML Group Sync ([GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/285150) and later) | | **User Removal** | SCIM (remove user from top-level group) | LDAP (remove user from groups and block from the instance) | diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md index 6064ae7525e..739f6b99722 100644 --- a/doc/administration/object_storage.md +++ b/doc/administration/object_storage.md @@ -293,7 +293,7 @@ in Google's [Cloud Storage authentication documentation](https://cloud.google.com/storage/docs/authentication). NOTE: -Bucket encryption with the [Cloud Key Management Service (KMS)](https://cloud.google.com/kms/docs) is not supported and will result in [ETag mismatch errors](#etag-mismatch). +Bucket encryption with the [Cloud Key Management Service (KMS)](https://cloud.google.com/kms/docs) is not supported and results in [ETag mismatch errors](#etag-mismatch). ##### Google example (consolidated form) @@ -583,8 +583,8 @@ With Omnibus and source installations it is possible to split a single real bucket into multiple virtual buckets. If your object storage bucket is called `my-gitlab-objects` you can configure uploads to go into `my-gitlab-objects/uploads`, artifacts into -`my-gitlab-objects/artifacts`, etc. The application will act as if -these are separate buckets. Note that use of bucket prefixes +`my-gitlab-objects/artifacts`, etc. The application acts as if +these are separate buckets. Use of bucket prefixes [may not work correctly with Helm backups](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3376). Helm-based installs require separate buckets to @@ -686,7 +686,7 @@ With the consolidated object configuration and instance profile, Workhorse has S3 credentials so that it can compute the `Content-MD5` header. This eliminates the need to compare ETag headers returned from the S3 server. -Encrypting buckets with GCS' [Cloud Key Management Service (KMS)](https://cloud.google.com/kms/docs) is not supported and will result in ETag mismatch errors. +Encrypting buckets with the GCS [Cloud Key Management Service (KMS)](https://cloud.google.com/kms/docs) is not supported and results in ETag mismatch errors. ### Using Amazon instance profiles @@ -817,5 +817,5 @@ Prerequisites: After you have done at least one successful Rclone copy from the old location to the new location, schedule maintenance and take your GitLab server offline. During your maintenance window you must do two things: -1. Perform a final `rclone sync` run, knowing that your users cannot add new objects so you will not leave any behind in the old bucket. +1. Perform a final `rclone sync` run, knowing that your users cannot add new objects so you do not leave any behind in the old bucket. 1. Update the object storage configuration of your GitLab server to use the new provider for `uploads`. diff --git a/doc/administration/sidekiq/processing_specific_job_classes.md b/doc/administration/sidekiq/processing_specific_job_classes.md index 080ad7d4eae..61a154c8db2 100644 --- a/doc/administration/sidekiq/processing_specific_job_classes.md +++ b/doc/administration/sidekiq/processing_specific_job_classes.md @@ -252,7 +252,7 @@ WARNING: As described in [the concurrency section](extra_sidekiq_processes.md#manage-thread-counts-explicitly), we recommend setting `min_concurrency` and `max_concurrency` to the same value. For example, if the number of queues in a queue group entry is 1, while `min_concurrency` is set to `0`, and `max_concurrency` is set to `20`, the resulting -concurrency will be set to `2` instead. A concurrency of `2` might be too low in most cases, except for very highly-CPU +concurrency is set to `2` instead. A concurrency of `2` might be too low in most cases, except for very highly-CPU bound tasks. ## Worker matching query @@ -310,8 +310,8 @@ highest to lowest precedence: and `query_b` are queries made up of the other operators here) includes queues that match either query. - `&` - the logical `AND` operator. For example, `query_a&query_b` (where - `query_a` and `query_b` are queries made up of the other operators here) will - only include queues that match both queries. + `query_a` and `query_b` are queries made up of the other operators here) + include only queues that match both queries. - `!=` - the `NOT IN` operator. For example, `feature_category!=issue_tracking` excludes all queues from the `issue_tracking` feature category. - `=` - the `IN` operator. For example, `resource_boundary=cpu` includes all diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md index b261e385949..8b95a9f6f0a 100644 --- a/doc/administration/sidekiq/sidekiq_troubleshooting.md +++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w Sidekiq is the background job processor GitLab uses to asynchronously run tasks. When things go wrong it can be difficult to troubleshoot. These situations also tend to be high-pressure because a production system job queue -may be filling up. Users will notice when this happens because new branches +may be filling up. Users notice when this happens because new branches may not show up and merge requests may not be updated. The following are some troubleshooting steps to help you diagnose the bottleneck. @@ -105,7 +105,7 @@ Gather data on the state of the Sidekiq workers with the following Ruby script. If the performance issue is intermittent: - - Run this in a cron job every five minutes. Write the files to a location with enough space: allow for 500KB per file. + - Run this in a cron job every five minutes. Write the files to a location with enough space: allow for 500 KB per file. - Refer back to the data to see what went wrong. 1. Analyze the output. The following commands assume that you have a directory of output files. @@ -269,7 +269,7 @@ corresponding Ruby code where this is happening. `gdb` can be another effective tool for debugging Sidekiq. It gives you a little more interactive way to look at each thread and see what's causing problems. -Attaching to a process with `gdb` suspends the normal operation +Attaching to a process with `gdb` suspends the standard operation of the process (Sidekiq does not process jobs while `gdb` is attached). Start by attaching to the Sidekiq PID: diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index cadff0bbdf6..8a03c152acb 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -19873,7 +19873,9 @@ Represents a Suggested Reviewers result set. | Name | Type | Description | | ---- | ---- | ----------- | | <a id="suggestedreviewerstypeaccepted"></a>`accepted` | [`[String!]`](#string) | List of accepted reviewer usernames. | +| <a id="suggestedreviewerstypecreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of when the suggestions were created. | | <a id="suggestedreviewerstypesuggested"></a>`suggested` | [`[String!]!`](#string) | List of suggested reviewer usernames. | +| <a id="suggestedreviewerstypeupdatedat"></a>`updatedAt` | [`Time!`](#time) | Timestamp of when the suggestions were updated. | ### `SystemNoteMetadata` diff --git a/doc/api/group_import_export.md b/doc/api/group_import_export.md index 989b7a66285..c648b6bad37 100644 --- a/doc/api/group_import_export.md +++ b/doc/api/group_import_export.md @@ -87,7 +87,7 @@ POST /groups/import | `name` | string | yes | The name of the group to be imported | | `path` | string | yes | Name and path for new group | | `file` | string | yes | The file to be uploaded | -| `parent_id` | integer | no | ID of a parent group that the group will be imported into. Defaults to the current user's namespace if not provided. | +| `parent_id` | integer | no | ID of a parent group to import the group into. Defaults to the current user's namespace if not provided. | To upload a file from your file system, use the `--form` argument. This causes cURL to post data using the header `Content-Type: multipart/form-data`. diff --git a/doc/development/database/table_partitioning.md b/doc/development/database/table_partitioning.md index 7489154d64a..fe92ebc768a 100644 --- a/doc/development/database/table_partitioning.md +++ b/doc/development/database/table_partitioning.md @@ -359,7 +359,7 @@ class PrepareForeignKeyForPartitioning < Gitlab::Database::Migration[2.1] target_column: [PARTITION_COLUMN, TARGET_COLUMN], validate: false, on_update: :cascade, - name: CONSTRAINT_NAME + name: FK_NAME ) # This should be done in a separate post migration when dealing with a high traffic table diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md index e185cd702a4..fd5b0ea15e6 100644 --- a/doc/development/experiment_guide/index.md +++ b/doc/development/experiment_guide/index.md @@ -63,3 +63,7 @@ We recommend the following workflow: 1. **If the experiment is a success**, designers add the new icon or illustration to the Pajamas UI kit as part of the cleanup process. Engineers can then add it to the [SVG library](https://gitlab-org.gitlab.io/gitlab-svgs/) and modify the implementation based on the [Frontend Development Guidelines](../fe_guide/icons.md#usage-in-hamlrails-2). + +## Related topics + +- [Experiments API](../../api/experiments.md) diff --git a/doc/operations/metrics/embed_grafana.md b/doc/operations/metrics/embed_grafana.md index 15969f0d6be..9b2a381fcf6 100644 --- a/doc/operations/metrics/embed_grafana.md +++ b/doc/operations/metrics/embed_grafana.md @@ -72,7 +72,7 @@ To generate a link to a panel: If you select the dashboard's share button instead, GitLab attempts to embed the first supported panel on the dashboard (if available). -1. If your Prometheus queries use Grafana's custom template variables, ensure the +1. If your Prometheus queries use the Grafana custom template variables, ensure the **Template variables** option is set to on. Only the Grafana global template variables `$__interval`, `$__from`, and `$__to` are supported. 1. Set the **Current time range** option to on, to specify the time range of the panel. Otherwise, diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 796cb71321a..5b0daf3010e 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -811,7 +811,7 @@ You must truncate the files referenced by the database that are causing the prob - In the `uploads` table. - In the references found. Any reference found from other database tables and columns. -- On the filesystem. +- On the file system. Truncate the filenames in the `uploads` table: @@ -979,7 +979,7 @@ Truncate the filenames in the references found: 1. Replace those long filenames using the new filenames obtained from querying the `uploads` table. -Truncate the filenames on the filesystem. You must manually rename the files in your filesystem to the new filenames obtained from querying the `uploads` table. +Truncate the filenames on the file system. You must manually rename the files in your file system to the new filenames obtained from querying the `uploads` table. #### Re-run the backup task diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md index e5d8d858df2..39cd8f8e074 100644 --- a/doc/security/crime_vulnerability.md +++ b/doc/security/crime_vulnerability.md @@ -27,7 +27,7 @@ files are here: - [Omnibus installation NGINX file](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb) Although SPDY is enabled in Omnibus installations, CRIME relies on compression -(the 'C') and the default compression level in NGINX's SPDY module is 0 +(the 'C') and the default compression level in the NGINX SPDY module is 0 (no compression). ## Nessus @@ -50,7 +50,7 @@ The following configuration indicates that the remote service may be vulnerable SPDY support earlier than version 4 is advertised. ``` -From the report above it is important to note that Nessus is only checking if +The report above indicates that Nessus is only checking if TLS advertises the SPDY protocol earlier than version 4. It does not perform an attack nor does it check if compression is enabled. The Nessus scanner alone cannot tell that SPDY compression is disabled and not subject to the CRIME diff --git a/doc/topics/git/how_to_install_git/index.md b/doc/topics/git/how_to_install_git/index.md index f3ea1431733..f3031acf35f 100644 --- a/doc/topics/git/how_to_install_git/index.md +++ b/doc/topics/git/how_to_install_git/index.md @@ -52,6 +52,20 @@ To install Git on macOS: git --version ``` +#### macOS update + +Periodically you may need to update the version of Git installed by +[Homebrew](/ee/topics/git/how_to_install_git/index.md#macos). To do so, +open a terminal and run these commands: + +```shell +brew update +brew upgrade git +``` + +To verify you are on the updated version, run `git --version` to display +your current version of Git. + ### Ubuntu Linux On Ubuntu and other Linux operating systems, use the built-in package manager @@ -73,6 +87,10 @@ from the officially git --version ``` +#### Ubuntu Linux Update + +Periodically it may be necessary to update Git installed. To do so, run the same [commands](/ee/topics/git/how_to_install_git/index.md#ubuntu-linux). + ### Windows Go to the [Git website](https://git-scm.com/), and then download and install Git for Windows. diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 1735810c3cc..0bf2e1fcc20 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -416,7 +416,7 @@ git commit -m 'Properly escape special characters in XML generation' An example of a good commit message is: "Combine templates to reduce duplicate code in the user views." The words "change," "improve," "fix," and "refactor" don't add much information to a commit message. -For more information, please see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). +For more information, see Tim Pope's excellent [note about formatting commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). To add more context to a commit message, consider adding information regarding the origin of the change. For example, the URL of a GitLab issue, or a Jira issue number, diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md index ec5f0a27643..793266dfcb1 100644 --- a/doc/update/deprecations.md +++ b/doc/update/deprecations.md @@ -1198,8 +1198,8 @@ WARNING: This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). Review the details carefully before upgrading. -The [Jira DVCS Connector](https://docs.gitlab.com/ee/integration/jira/dvcs.html) (which enables the [Jira Development Panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)), will no longer support Jira Cloud users starting with GitLab 16.0. The [GitLab for Jira App](https://docs.gitlab.com/ee/integration/jira/connect-app.html) has always been recommended for Jira Cloud users, and it will be required instead of the DVCS connector. If you are a Jira Cloud user, we recommended you begin migrating to the GitLab for Jira App. -Any Jira Server and Jira Data Center users will need to confirm they are not using the GitHub Enterprise Connector to enable the GitLab DVCS integration, but they may continue to use the [native GitLab DVCS integration](https://docs.gitlab.com/ee/integration/jira/dvcs.html) (supported in Jira 8.14 and later). +The [Jira DVCS Connector](https://docs.gitlab.com/ee/integration/jira/dvcs/) (which enables the [Jira Development Panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)), will no longer support Jira Cloud users starting with GitLab 16.0. The [GitLab for Jira App](https://docs.gitlab.com/ee/integration/jira/connect-app.html) has always been recommended for Jira Cloud users, and it will be required instead of the DVCS connector. If you are a Jira Cloud user, we recommended you begin migrating to the GitLab for Jira App. +Any Jira Server and Jira Data Center users will need to confirm they are not using the GitHub Enterprise Connector to enable the GitLab DVCS integration, but they may continue to use the [native GitLab DVCS integration](https://docs.gitlab.com/ee/integration/jira/dvcs/) (supported in Jira 8.14 and later). </div> diff --git a/doc/user/admin_area/appearance.md b/doc/user/admin_area/appearance.md index a65c0c86649..d9bdf964aed 100644 --- a/doc/user/admin_area/appearance.md +++ b/doc/user/admin_area/appearance.md @@ -60,7 +60,7 @@ to activate it in the GitLab instance. You can replace the default message on the sign in / sign up page with your own message and logo. You can make full use of [Markdown](../markdown.md) in the description. -The optimal size for the logo is 640x360px, but any image can be used (below 1MB) +The optimal size for the logo is 640 x 360 pixels, but any image can be used (below 1 MB) and it is resized automatically. The logo image appears between the title and the description, on the left of the sign-up page. diff --git a/doc/user/admin_area/geo_sites.md b/doc/user/admin_area/geo_sites.md index f3be036fd38..9fe36188dd0 100644 --- a/doc/user/admin_area/geo_sites.md +++ b/doc/user/admin_area/geo_sites.md @@ -52,7 +52,7 @@ How long the backfill takes is dependent on the maximum concurrency, but higher values place more strain on the **primary** site. The limits are configurable. If your **primary** site has lots of surplus capacity, you can increase the values to complete backfill in a shorter time. If it's -under heavy load and backfill reduces its availability for normal requests, +under heavy load and backfill reduces its availability for standard requests, you can decrease them. ## Set up the internal URLs diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md index 3d96eaf793f..cdffce8abe2 100644 --- a/doc/user/admin_area/moderate_users.md +++ b/doc/user/admin_area/moderate_users.md @@ -69,7 +69,7 @@ GitLab administrators can block and unblock users. ### Block a user -In order to completely prevent access of a user to the GitLab instance, +To completely prevent access of a user to the GitLab instance, administrators can choose to block the user. Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users), @@ -129,7 +129,7 @@ GitLab administrators can deactivate and activate users. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22257) in GitLab 12.4. -In order to temporarily prevent access by a GitLab user that has no recent activity, +To temporarily prevent access by a GitLab user that has no recent activity, administrators can choose to deactivate the user. Deactivating a user is functionally identical to [blocking a user](#block-and-unblock-users), diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md index 483954ce7a9..982aa11a7b2 100644 --- a/doc/user/admin_area/settings/continuous_integration.md +++ b/doc/user/admin_area/settings/continuous_integration.md @@ -91,7 +91,7 @@ can be set at: For the setting on GitLab.com, see [Artifacts maximum size](../../gitlab_com/index.md#gitlab-cicd). -The value is in MB and the default is 100MB per job. To change it at the: +The value is in MB and the default is 100 MB per job. To change it at the: - Instance level: diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md index 5be9081d9b2..1e7c75363ab 100644 --- a/doc/user/admin_area/settings/project_integration_management.md +++ b/doc/user/admin_area/settings/project_integration_management.md @@ -28,7 +28,7 @@ Only the complete settings for an integration can be inherited. Per-field inheri 1. Enter configuration details and select **Save changes**. WARNING: -This may affect all or most of the groups and projects on your GitLab instance. Please review the details +This may affect all or most of the groups and projects on your GitLab instance. Review the details below. If this is the first time you are setting up instance-level settings for an integration: @@ -82,7 +82,7 @@ for an integration. 1. Enter configuration details and select **Save changes**. WARNING: -This may affect all or most of the subgroups and projects belonging to the group. Please review the details below. +This may affect all or most of the subgroups and projects belonging to the group. Review the details below. If this is the first time you are setting up group-level settings for an integration: diff --git a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md index 3c6fd4b1e45..547e543ab88 100644 --- a/doc/user/admin_area/settings/rate_limit_on_issues_creation.md +++ b/doc/user/admin_area/settings/rate_limit_on_issues_creation.md @@ -22,7 +22,7 @@ For example, if you set a limit of 300, requests using the [Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/issues_controller.rb) action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute. -When using [epics](../../group/epics/index.md), epic creation will share this rate limit with issues. +When using [epics](../../group/epics/index.md), epic creation shares this rate limit with issues. ![Rate limits on issues creation](img/rate_limit_on_issues_creation_v14_2.png) diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 8aabe503065..9f1d4eea851 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -142,7 +142,7 @@ Existing passwords are unaffected. To change password complexity requirements: You can specify an inclusive or exclusive list of email domains which can be used for user sign up. These restrictions are only applied during sign up from an external user. An administrator can add a -user through the administrator panel with a disallowed domain. Also, note that the users can change their +user through the administrator panel with a disallowed domain. The users can also change their email addresses to disallowed domains after sign up. ### Allowlist email domains diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md index e285275f5bb..9b8718fc336 100644 --- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md +++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md @@ -140,7 +140,7 @@ It is important that your load balancer erases or overwrites the bypass header on all incoming traffic. Otherwise, you must trust your users to not set that header and bypass the GitLab rate limiter. -Note that the bypass only works if the header is set to `1`. +The bypass works only if the header is set to `1`. Requests that bypassed the rate limiter because of the bypass header are marked with `"throttle_safelist":"throttle_bypass_header"` in @@ -209,7 +209,7 @@ To enable dry run mode for all throttles, the variable can be set to `*`. Setting a throttle to dry run mode logs a message to the [`auth.log`](../../../administration/logs/index.md#authlog) when it would hit the limit, while letting the -request continue as normal. The log message contains an `env` field set to `track`. The `matched` +request continue. The log message contains an `env` field set to `track`. The `matched` field contains the name of throttle that was hit. It is important to set the environment variable **before** enabling diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index fc06b50b03d..b5792cbfe5b 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -234,7 +234,7 @@ When you enable this feature, you may see [duplicate findings](../terminology/in in the [Vulnerability Report](../vulnerability_report/index.md) if [Dependency Scanning](../dependency_scanning/index.md) is enabled for your project. This happens because GitLab can't automatically deduplicate findings -across different types of scanning tools. Please reference [this comparison](../dependency_scanning/index.md#dependency-scanning-compared-to-container-scanning) +across different types of scanning tools. Reference [this comparison](../dependency_scanning/index.md#dependency-scanning-compared-to-container-scanning) between GitLab Dependency Scanning and Container Scanning for more details on which types of dependencies are likely to be duplicated. #### Available CI/CD variables @@ -532,7 +532,7 @@ To use container scanning in an offline environment, you need: | --- | --- | | [Container-Scanning](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) | [Container-Scanning container registry](https://gitlab.com/security-products/container-scanning/container_registry/) | -Note that GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy), +GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy), meaning the runner tries to pull Docker images from the GitLab container registry even if a local copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy) in an offline environment if you prefer using only locally available Docker images. However, we @@ -560,7 +560,7 @@ registry.gitlab.com/security-products/container-scanning/trivy:5 ``` The process for importing Docker images into a local offline Docker registry depends on -**your network security policy**. Please consult your IT staff to find an accepted and approved +**your network security policy**. Consult your IT staff to find an accepted and approved process by which you can import or temporarily access external resources. These scanners are [periodically updated](../index.md#vulnerability-scanner-maintenance), and you may be able to make occasional updates on your own. diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index 283e48ec499..3cb8967afd2 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -57,7 +57,7 @@ which GitLab uses to determine discovered vulnerabilities based on differences b #### Recommendations -- Take care if your pipeline is configured to deploy to the same web server in each run. Running a DAST scan while a server is being updated will lead to inaccurate and non-deterministic results. +- Take care if your pipeline is configured to deploy to the same web server in each run. Running a DAST scan while a server is being updated leads to inaccurate and non-deterministic results. - Configure runners to use the [always pull policy](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy) to run the latest versions of the analyzers. - By default, DAST downloads all artifacts defined by previous jobs in the pipeline. If your DAST job does not rely on `environment_url.txt` to define the URL under test or any other files created @@ -71,7 +71,7 @@ which GitLab uses to determine discovered vulnerabilities based on differences b #### Analyzer configuration -Please see [DAST proxy-based analyzer](proxy-based.md), [DAST browser-based analyzer](browser_based.md) or [DAST API analyzer](../dast_api/index.md) for +See [DAST proxy-based analyzer](proxy-based.md), [DAST browser-based analyzer](browser_based.md) or [DAST API analyzer](../dast_api/index.md) for analyzer-specific configuration instructions. ### View scan results @@ -83,8 +83,8 @@ and the [Vulnerability report](../index.md#view-security-scan-information-in-the 1. To see all vulnerabilities detected, either: - From your project, select **Security & Compliance**, then **Vulnerability report**. - - From your pipeline, click on the **Security** tab. - - From the merge request, go to the **Security scanning** widget and click **Full report** tab. + - From your pipeline, select the **Security** tab. + - From the merge request, go to the **Security scanning** widget and select **Full report** tab. 1. Select a DAST vulnerability's description. The following fields are examples of what a DAST analyzer may produce to aid investigation and rectification of the underlying cause. Each analyzer may output different fields. @@ -142,7 +142,7 @@ After your Docker build job completes and your image is added to your container By using service definitions in your `.gitlab-ci.yml`, you can scan services with the DAST analyzer. -When adding a `services` section to the job, the `alias` is used to define the hostname that can be used to access the service. In the following example, the `alias: yourapp` portion of the `dast` job definition means that the URL to the deployed application will use `yourapp` as the hostname (`https://yourapp/`). +When adding a `services` section to the job, the `alias` is used to define the hostname that can be used to access the service. In the following example, the `alias: yourapp` portion of the `dast` job definition means that the URL to the deployed application uses `yourapp` as the hostname (`https://yourapp/`). ```yaml stages: diff --git a/doc/user/application_security/dast/proxy-based.md b/doc/user/application_security/dast/proxy-based.md index 605d243f72e..f70afac4c26 100644 --- a/doc/user/application_security/dast/proxy-based.md +++ b/doc/user/application_security/dast/proxy-based.md @@ -9,7 +9,7 @@ type: reference, howto The DAST proxy-based analyzer can be added to your [GitLab CI/CD](../../../ci/index.md) pipeline. This helps you discover vulnerabilities in web applications that do not use JavaScript heavily. For applications that do, -please see the [DAST browser-based analyzer](browser_based.md). +see the [DAST browser-based analyzer](browser_based.md). WARNING: Do not run DAST scans against a production server. Not only can it perform *any* function that @@ -231,7 +231,7 @@ variables: > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214120) in GitLab 13.4. To specify the paths to scan in a CI/CD variable, add a comma-separated list of the paths to the `DAST_PATHS` -variable. Note that you can only scan paths of a single host. +variable. You can only scan paths of a single host. ```yaml include: @@ -247,7 +247,7 @@ When using `DAST_PATHS` and `DAST_PATHS_FILE`, note the following: - `DAST_WEBSITE` must be defined when using either `DAST_PATHS_FILE` or `DAST_PATHS`. The paths listed in either use `DAST_WEBSITE` to build the URLs to scan - Spidering is disabled when `DAST_PATHS` or `DAST_PATHS_FILE` are defined - `DAST_PATHS_FILE` and `DAST_PATHS` cannot be used together -- The `DAST_PATHS` variable has a limit of about 130kb. If you have a list or paths +- The `DAST_PATHS` variable has a limit of about 130 kb. If you have a list or paths greater than this, use `DAST_PATHS_FILE`. #### Full Scan @@ -428,7 +428,7 @@ dast: The ZAProxy server contains many [useful configurable values](https://gitlab.com/gitlab-org/gitlab/-/issues/36437#note_245801885). Many key/values for `-config` remain undocumented, but there is an untested list of [possible keys](https://gitlab.com/gitlab-org/gitlab/-/issues/36437#note_244981023). -Note that these options are not supported by DAST, and may break the DAST scan +These options are not supported by DAST, and may break the DAST scan when used. An example of how to rewrite the Authorization header value with `TOKEN` follows: ```yaml diff --git a/doc/user/application_security/dependency_list/index.md b/doc/user/application_security/dependency_list/index.md index 9fffdec2612..b86d98471ac 100644 --- a/doc/user/application_security/dependency_list/index.md +++ b/doc/user/application_security/dependency_list/index.md @@ -81,7 +81,7 @@ You can download your project's full list of dependencies and their details in ### In the UI -You can download your project's list of dependencies and their details in JSON format by selecting the **Export** button. Note that the dependency list only shows the results of the last successful pipeline to run on the default branch. +You can download your project's list of dependencies and their details in JSON format by selecting the **Export** button. The dependency list only shows the results of the last successful pipeline to run on the default branch. ### Using the API diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md index 6d0d444497e..8593fa50a05 100644 --- a/doc/user/project/file_lock.md +++ b/doc/user/project/file_lock.md @@ -10,7 +10,7 @@ Preventing wasted work caused by unresolvable merge conflicts requires a different way of working. This means explicitly requesting write permissions, and verifying no one else is editing the same file before you start. -Although branching strategies usually work well enough for source code and +Although branching strategies typically work well enough for source code and plain text because different versions can be merged together, they do not work for binary files. diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md index 9bc960f3696..f22509ffe81 100644 --- a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md +++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md @@ -105,7 +105,7 @@ server running on your instance). ![DNS `A` record pointing to GitLab.com Pages server](img/dns_add_new_a_record_example_updated_2018.png) WARNING: -Note that if you use your root domain for your GitLab Pages website +If you use your root domain for your GitLab Pages website **only**, and if your domain registrar supports this feature, you can add a DNS apex `CNAME` record instead of an `A` record. The main advantage of doing so is that when GitLab Pages IP on GitLab.com @@ -125,7 +125,7 @@ Subdomains (`subdomain.example.com`) require: | `subdomain.example.com` | `ALIAS`/`CNAME` | `namespace.gitlab.io` | | `_gitlab-pages-verification-code.subdomain.example.com` | `TXT` | `gitlab-pages-verification-code=00112233445566778899aabbccddeeff` | -Note that, whether it's a user or a project website, the DNS record +Whether it's a user or a project website, the DNS record should point to your Pages domain (`namespace.gitlab.io`), without any `/project-name`. @@ -190,7 +190,7 @@ from the GitLab project. > - Domain verification is **required for GitLab.com users**; for GitLab self-managed instances, your GitLab administrator has the option to [disabled custom domain verification](../../../../administration/pages/index.md#custom-domain-verification). -> - [DNS propagation may take some time (up to 24h)](https://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/complete-guide-to-dns-records/), +> - [DNS propagation may take some time (up to 24 hours)](https://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/complete-guide-to-dns-records/), although it's usually a matter of minutes to complete. Until it does, verification fails, and attempts to visit your domain result in a 404. > - Once your domain has been verified, leave the verification record diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md index b9d2f8cb9a6..398d8dc6e1e 100644 --- a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md +++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md @@ -29,7 +29,7 @@ This might be your first question. If our sites are hosted by GitLab Pages, they are static, hence we are not dealing with server-side scripts nor credit card transactions, then why do we need secure connections? -Back in the 1990s, where HTTPS came out, [SSL](https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0) was considered a "special" +When HTTPS came out in 1990, [SSL](https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0) was considered a "special" security measure, necessary just for big companies like banks and shopping sites with financial transactions. @@ -60,7 +60,7 @@ reiterating the importance of HTTPS. GitLab Pages accepts certificates provided in the [PEM](https://knowledge.digicert.com/quovadis.html) format, issued by [Certificate Authorities](https://en.wikipedia.org/wiki/Certificate_authority) or as -[self-signed certificates](https://en.wikipedia.org/wiki/Self-signed_certificate). Note that [self-signed certificates are typically not used](https://www.mcafee.com/blogs/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/) +[self-signed certificates](https://en.wikipedia.org/wiki/Self-signed_certificate). [Self-signed certificates are typically not used](https://www.mcafee.com/blogs/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/) for public websites for security reasons and to ensure that browsers trust your site's certificate. There are various kinds of certificates, each one diff --git a/doc/user/project/pages/public_folder.md b/doc/user/project/pages/public_folder.md index 8c9f1cbec86..751db136e34 100644 --- a/doc/user/project/pages/public_folder.md +++ b/doc/user/project/pages/public_folder.md @@ -17,7 +17,7 @@ for the following frameworks. For Eleventy, you should do one of the following: -- Add the `--output=public` flag in Eleventy's build commands, for example: +- Add the `--output=public` flag in the Eleventy build commands, for example: `npx @11ty/eleventy --input=path/to/sourcefiles --output=public` diff --git a/doc/user/project/releases/release_fields.md b/doc/user/project/releases/release_fields.md index c06e746268f..120bbe32a63 100644 --- a/doc/user/project/releases/release_fields.md +++ b/doc/user/project/releases/release_fields.md @@ -34,7 +34,7 @@ Every release has a description. You can add any text you like, but we recommend including a changelog to describe the content of your release. This helps users quickly scan the differences between each release you publish. -[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) can +[Tagging messages in Git](https://git-scm.com/book/en/v2/Git-Basics-Tagging) can be included in Release note descriptions by selecting **Include tag message in the release notes**. |