diff --git a/.vale.ini b/.vale.ini index 25353f97023342b5d66855ceefdd0ed7d81094f7..89a669ec7ff8aaaee1a75e8c77b6725cae51136c 100644 --- a/.vale.ini +++ b/.vale.ini @@ -38,12 +38,3 @@ BasedOnStyles = gitlab # To change the reporting level (suggestion, warning, error) of a rule, # use the following format: {style}.{filename} = {level} # vale.Hedging = error - -# Syntax-specific settings -# ------------------------ -# You can configure specific tests to be enabled, disabled, or report at a -# different level for specific file types. File-type-specific settings added -# here will overwrite any conflicting global settings. -[*.{md,txt}] -# vale.Editorializing = NO - diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 0e13508a3cdba6059e3e72bbb7dd0e4990ceb794..cbb01c41002511e811a18ec64a144d4cd80aee84 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check Checking Geo ... Finished ``` - When performing a Postgres major version (9 > 10) update this is expected. Follow: + When performing a Postgres major version (9 > 10) update this is expected. Follow: - [initiate-the-replication-process](https://docs.gitlab.com/ee/administration/geo/replication/database.html#step-3-initiate-the-replication-process) - [Geo database has an outdated FDW remote schema](https://docs.gitlab.com/ee/administration/geo/replication/troubleshooting.html#geo-database-has-an-outdated-fdw-remote-schema-error) diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index 1ef903f4cf3309227bf9cfb765627023bf324eea..2ed259dad4ab2b9978c0de678ed5acb8e9050b38 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -108,7 +108,7 @@ Reports that go over the 20 MB limit won't be loaded. Affected reports: > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/201826) in GitLab 12.8. You can set a limit on the content of text fields indexed for Global Search. -Setting a maximum helps to reduce the load of the indexing processes. If any +Setting a maximum helps to reduce the load of the indexing processes. If any text field exceeds this limit then the text will be truncated to this number of characters and the rest will not be indexed and hence will not be searchable. diff --git a/doc/administration/invalidate_markdown_cache.md b/doc/administration/invalidate_markdown_cache.md index 7bebf555a6cb16011cbe4cabfcdfba9c10e80c30..5fd804e11dc03a63cce7d164bd67cb14fb862f38 100644 --- a/doc/administration/invalidate_markdown_cache.md +++ b/doc/administration/invalidate_markdown_cache.md @@ -7,7 +7,7 @@ when the `external_url` configuration option is changed - causing links in the cached text to refer to the old URL. To avoid this problem, the administrator can invalidate the existing cache by -increasing the `local_markdown_version` setting in application settings. This can +increasing the `local_markdown_version` setting in application settings. This can be done by [changing the application settings through the API](../api/settings.md#change-application-settings): diff --git a/doc/api/README.md b/doc/api/README.md index f179885c525522e58657b209aabc073bbe7abe0a..a261e1e7dc6e1238f119f425a06ee447d2b491dc 100644 --- a/doc/api/README.md +++ b/doc/api/README.md @@ -449,7 +449,7 @@ GET /api/v4/projects/diaspora%2Fdiaspora ``` NOTE: **Note:** -A project's **path** is not necessarily the same as its **name**. A +A project's **path** is not necessarily the same as its **name**. A project's path can be found in the project's URL or in the project's settings under **General > Advanced > Change path**. diff --git a/doc/api/users.md b/doc/api/users.md index 601db1c790b0a62ae81c5e0da798d857f36df310..2dd07ab8a4e6cd53d90dc2101f4bf161d97fc2b1 100644 --- a/doc/api/users.md +++ b/doc/api/users.md @@ -1168,7 +1168,7 @@ Will return `201 OK` on success, `404 User Not Found` is user cannot be found or > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/22257) in GitLab 12.4. -Deactivates the specified user. Available only for admin. +Deactivates the specified user. Available only for admin. ``` POST /users/:id/deactivate @@ -1190,7 +1190,7 @@ Returns: > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/22257) in GitLab 12.4. -Activates the specified user. Available only for admin. +Activates the specified user. Available only for admin. ``` POST /users/:id/activate diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md index 018e0c4b84de111d8f62c59060614ce9c14e17d3..621b679de739af2b2e2fb35fdaa4b318696c3906 100644 --- a/doc/ci/docker/using_docker_images.md +++ b/doc/ci/docker/using_docker_images.md @@ -642,7 +642,7 @@ Specifying only `registry.example.com` will not work. ### Configuring a Runner If you have many pipelines that access the same registry, it'll -probably be better to setup registry access at the runner level. This +probably be better to setup registry access at the runner level. This allows pipeline authors to have access to a private registry just by running a job on the appropriate runner. It also makes registry changes and credential rotations much simpler. diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index 5cc93427d4209e81b68b2b9b3bacdf4a4f57f7a0..dd15b8c37b11bb6482037821ccf7be29abb3ab12 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -99,7 +99,7 @@ future GitLab releases.** | `CI_PROJECT_TITLE` | 12.4 | all | The human-readable project name as displayed in the GitLab web interface. | | `CI_PROJECT_URL` | 8.10 | 0.5 | The HTTP(S) address to access project | | `CI_PROJECT_VISIBILITY` | 10.3 | all | The project visibility (internal, private, public) | -| `CI_REGISTRY` | 8.10 | 0.5 | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable will include a `:port` value if one has been specified in the registry configuration. | +| `CI_REGISTRY` | 8.10 | 0.5 | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable will include a `:port` value if one has been specified in the registry configuration. | | `CI_REGISTRY_IMAGE` | 8.10 | 0.5 | If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project | | `CI_REGISTRY_PASSWORD` | 9.0 | all | The password to use to push containers to the GitLab Container Registry | | `CI_REGISTRY_USER` | 9.0 | all | The username to use to push containers to the GitLab Container Registry | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 881f32976956516f6f33c17a06067389569ae3fb..a516a3f56f704e6adf15106889f1ba22dd7447c1 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1523,7 +1523,7 @@ globally and all jobs will use that definition. Use the `paths` directive to choose which files or directories will be cached. Paths are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) -patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match). +patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match). Cache all files in `binaries` that end in `.apk` and the `.config` file: @@ -1755,7 +1755,7 @@ be available for download in the GitLab UI. Paths are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) -patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match). +patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match). To restrict which jobs a specific job will fetch artifacts from, see [dependencies](#dependencies). @@ -3212,9 +3212,9 @@ spinach: ``` In GitLab 12.0 and later, it's also possible to use multiple parents for -`extends`. The algorithm used for merge is "closest scope wins", so +`extends`. The algorithm used for merge is "closest scope wins", so keys from the last member will always shadow anything defined on other -levels. For example: +levels. For example: ```yaml .only-important: diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index 3600c43aa4f1138fa6e09c18a65ec5deab7fe671..e8aa33b31a7b7342c691c7d5f4e31e1daf7a650c 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -180,8 +180,8 @@ query($project_path: ID!) { ``` To ensure that we get consistent ordering, we will append an ordering on the primary -key, in descending order. This is usually `id`, so basically we will add `order(id: :desc)` -to the end of the relation. A primary key _must_ be available on the underlying table. +key, in descending order. This is usually `id`, so basically we will add `order(id: :desc)` +to the end of the relation. A primary key _must_ be available on the underlying table. ### Exposing permissions for a type diff --git a/doc/development/emails.md b/doc/development/emails.md index 5617d9d43f2b7de54b35baf7988f89b80f42788d..133434523ec13d008706b7c3642c67909c712053 100644 --- a/doc/development/emails.md +++ b/doc/development/emails.md @@ -79,17 +79,17 @@ See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html# ## Email namespace -As of GitLab 11.7, we support a new format for email handler addresses. This was done to +As of GitLab 11.7, we support a new format for email handler addresses. This was done to support catch-all mailboxes. If you need to implement a feature which requires a new email handler, follow these rules for the format of the email key: -- Actions are always at the end, separated by `-`. For example `-issue` or `-merge-request` +- Actions are always at the end, separated by `-`. For example `-issue` or `-merge-request` - If your feature is related to a project, the key begins with the project identifiers (project path slug - and project id), separated by `-`. For example, `gitlab-org-gitlab-foss-20` + and project id), separated by `-`. For example, `gitlab-org-gitlab-foss-20` - Additional information, such as an author's token, can be added between the project identifiers and - the action, separated by `-`. For example, `gitlab-org-gitlab-foss-20-Author_Token12345678-issue` + the action, separated by `-`. For example, `gitlab-org-gitlab-foss-20-Author_Token12345678-issue` - You register your handlers in `lib/gitlab/email/handler.rb` Examples of valid email keys: diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index 1be09bfeddfe14abefb186c08dfa7abda62d5f8b..27cd0370bba3c406e03c93cfe15107d985f83811 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -40,7 +40,7 @@ of possible security breaches in our code: - SQL injections Remember to run -[SAST](../../user/application_security/sast/index.md) +[SAST](../../user/application_security/sast/index.md) and [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) **(ULTIMATE)** on your project (or at least the [gosec analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)), and to follow our [Security diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md index 3ef54ca6dd3b4bfab3d65984af763ca596a7ff5b..2d53e021f81cc03f2d73f6c33821114c97a74a9d 100644 --- a/doc/integration/elasticsearch.md +++ b/doc/integration/elasticsearch.md @@ -466,13 +466,13 @@ When performing a search, the GitLab index will use the following scopes: ### Deleted documents -Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted. However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases. Elasticsearch does intelligent merging of segments in order to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index. +Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted. However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases. Elasticsearch does intelligent merging of segments in order to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index. In general, we recommend simply letting Elasticsearch merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_ However, some larger installations may wish to tune the merge policy settings: -- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently. +- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently. ```shell curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' --data '{ @@ -482,7 +482,7 @@ However, some larger installations may wish to tune the merge policy settings: }' ``` -- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs. +- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs. ```shell curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' --data '{ @@ -492,7 +492,7 @@ However, some larger installations may wish to tune the merge policy settings: }' ``` -- Do not do a [force merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") to remove deleted documents. A warning in the [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") states that this can lead to very large segments that may never get reclaimed, and can also cause significant performance or availability issues. +- Do not do a [force merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") to remove deleted documents. A warning in the [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") states that this can lead to very large segments that may never get reclaimed, and can also cause significant performance or availability issues. ## Troubleshooting diff --git a/doc/integration/saml.md b/doc/integration/saml.md index c5c918e42823b2b237635e91fd5f43a3da7c59cf..10319b83233145df9ac0409e7b3874736fc31ed4 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -243,7 +243,7 @@ considered `admin groups`. >**Note:** This setting is only available on GitLab 11.4 EE and above. -This setting also follows the requirements documented for the `External Groups` setting. GitLab uses the Group information provided by your IdP to determine if a user should be assigned the `auditor` role. +This setting also follows the requirements documented for the `External Groups` setting. GitLab uses the Group information provided by your IdP to determine if a user should be assigned the `auditor` role. ```yaml { name: 'saml', @@ -374,7 +374,7 @@ in the OmniAuth [info hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash- For example, if your SAMLResponse contains an Attribute called 'EmailAddress', specify `{ email: ['EmailAddress'] }` to map the Attribute to the -corresponding key in the info hash. URI-named Attributes are also supported, e.g. +corresponding key in the info hash. URI-named Attributes are also supported, e.g. `{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`. This setting allows you tell GitLab where to look for certain attributes required diff --git a/doc/integration/vault.md b/doc/integration/vault.md index ea3aeeb0f6446d659ad4588db2e1ec04ddedcce3..2afa1ba7e320fcefbe575c8deccee7b7ba6aa558 100644 --- a/doc/integration/vault.md +++ b/doc/integration/vault.md @@ -65,7 +65,7 @@ The following assumes you already have Vault installed and running. 1. **Write the OIDC Role Config:** - Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab: + Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab: This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI. diff --git a/doc/migrate_ci_to_ce/README.md b/doc/migrate_ci_to_ce/README.md index d3db485820f69ad3a2c90e4d2ed5e75ce803635a..86720aca15872bf3f2a1884f7b84ae19f8bb1b5c 100644 --- a/doc/migrate_ci_to_ce/README.md +++ b/doc/migrate_ci_to_ce/README.md @@ -129,7 +129,7 @@ First upgrade your GitLab server to version 8.0: ### 2. Disable CI on the GitLab server during the migration -After you update, go to the admin panel and temporarily disable CI. As +After you update, go to the admin panel and temporarily disable CI. As an administrator, go to **Admin Area** -> **Settings**, and under **Continuous Integration** uncheck **Disable to prevent CI usage until rake ci:migrate is run (8.0 only)**. diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index b0b7b9526b355a333c7025a8152a4a658f97a4d4..8123b4ca7a7b622b8d98004afbfc67693f464c10 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -728,7 +728,7 @@ This procedure assumes that: - You have installed the **exact same version and type (CE/EE)** of GitLab Omnibus with which the backup was created. - You have run `sudo gitlab-ctl reconfigure` at least once. -- GitLab is running. If not, start it using `sudo gitlab-ctl start`. +- GitLab is running. If not, start it using `sudo gitlab-ctl start`. First make sure your backup tar file is in the backup directory described in the `gitlab.rb` configuration `gitlab_rails['backup_path']`. The default is @@ -739,7 +739,7 @@ sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backu sudo chown git.git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar ``` -Stop the processes that are connected to the database. Leave the rest of GitLab +Stop the processes that are connected to the database. Leave the rest of GitLab running: ```shell diff --git a/doc/raketasks/list_repos.md b/doc/raketasks/list_repos.md index cfcf11cf3c2a90fa2372f4e20c0a599f51e83725..21de27c5249fc1892c21c35aefa2f3ba087cc659 100644 --- a/doc/raketasks/list_repos.md +++ b/doc/raketasks/list_repos.md @@ -13,7 +13,7 @@ sudo -u git -H bundle exec rake gitlab:list_repos RAILS_ENV=production ``` If you only want to list projects with recent activity you can pass -a date with the 'SINCE' environment variable. The time you specify +a date with the 'SINCE' environment variable. The time you specify is parsed by the Rails [TimeZone#parse function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse). diff --git a/doc/ssh/README.md b/doc/ssh/README.md index bc34df4086d8ddb8f13f7082daf1e7681218c2bd..07abfa4cdacffc7b042daf490ef597db99a6af47 100644 --- a/doc/ssh/README.md +++ b/doc/ssh/README.md @@ -368,7 +368,7 @@ be configured on any repository in the entire GitLab installation. This is really useful for integrating repositories to secured, shared Continuous Integration (CI) services or other shared services. GitLab administrators can set up the Global Shared Deploy key in GitLab and -add the private key to any shared systems. Individual repositories opt into +add the private key to any shared systems. Individual repositories opt into exposing their repository using these keys when a project maintainers (or higher) authorizes a Global Shared Deploy key to be used with their project. diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index 0841daefde380594c26727be00b2b2c172549c85..52b92c98482e0ccdb86c7956d7cb7e20b2fccf92 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -30,7 +30,7 @@ This information is used, among other things, to identify to which versions patches will need to be backported, making sure active GitLab instances remain secure. -If you disable version check, this information will not be collected. Enable or +If you disable version check, this information will not be collected. Enable or disable the version check in **Admin Area > Settings > Metrics and profiling > Usage statistics**. ### Request flow example diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md index 1e67ac884679ce898f8a4124950016557ef6f0d6..8f64e9207b522414baf2fea99e5f6dd1af5dd1a2 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -15,7 +15,7 @@ To access the visibility and access control options: ## Default branch protection This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete -branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_. +branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_. This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md). diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index c8ea5ee5e480ea35eed249a8256df8ae6eac4463..3bdda338b76d1bdcf3f9d3ddc80434fba3d1baa4 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/doc/user/application_security/container_scanning/index.md @@ -170,7 +170,7 @@ using environment variables. | `DOCKER_PASSWORD` | Password for accessing a Docker registry requiring authentication. | `$CI_REGISTRY_PASSWORD` | | `CLAIR_OUTPUT` | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold will be outputted. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical` and `Defcon1`. | `Unknown` | | `REGISTRY_INSECURE` | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | `"false"` | -| `CLAIR_VULNERABILITIES_DB_URL` | This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/blob/30522ca8b901223ac8c32b633d8d67f340b159c1/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L17-19) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/klar/#running-the-scanning-tool) section of the [GitLab klar analyzer readme](https://gitlab.com/gitlab-org/security-products/analyzers/klar). | `clair-vulnerabilities-db` | +| `CLAIR_VULNERABILITIES_DB_URL` | This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/blob/30522ca8b901223ac8c32b633d8d67f340b159c1/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L17-19) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/klar/#running-the-scanning-tool) section of the [GitLab klar analyzer readme](https://gitlab.com/gitlab-org/security-products/analyzers/klar). | `clair-vulnerabilities-db` | | `CI_APPLICATION_REPOSITORY` | Docker repository URL for the image to be scanned. | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | | `CI_APPLICATION_TAG` | Docker respository tag for the image to be scanned. | `$CI_COMMIT_SHA` | | `CLAIR_DB_IMAGE` | The Docker image name and tag for the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation. | `arminc/clair-db:latest` | @@ -211,7 +211,7 @@ Container Scanning can be executed on an offline air-gapped GitLab Ultimate inst CLAIR_DB_IMAGE: $CI_REGISTRY/namespace/clair-vulnerabilities-db ``` -It may be worthwhile to set up a [scheduled pipeline](../../project/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule. You can use the following `.gitlab-yml.ci` as a template: +It may be worthwhile to set up a [scheduled pipeline](../../project/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule. You can use the following `.gitlab-yml.ci` as a template: ```yaml image: docker:stable diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index 03bd5cb276df942f283b6efd7928c4289c7e1e8c..07b5da1fd931273c91b4a1eb8a9956f77fb46be2 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/doc/user/application_security/dependency_scanning/index.md @@ -64,7 +64,7 @@ The following languages and dependency managers are supported. | Python ([poetry](https://poetry.eustace.io/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/7006 "Support Poetry in Dependency Scanning")) | not available | | Ruby ([gem](https://rubygems.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [bundler-audit](https://github.com/rubysec/bundler-audit) | | Scala ([sbt](https://www.scala-sbt.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) | -| Go ([Golang](https://golang.org/)) | yes ([alpha](https://gitlab.com/gitlab-org/gitlab/issues/7132)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) | +| Go ([Go Modules](https://github.com/golang/go/wiki/Modules)) | yes ([alpha](https://gitlab.com/gitlab-org/gitlab/issues/7132)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) | ## Configuration diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index 0567c84a66c4d0e8d5946f72d2b9b188540c02fd..e1bd9ca742b5758cdb22cbcde10160f68df2932a 100644 --- a/doc/user/application_security/index.md +++ b/doc/user/application_security/index.md @@ -118,7 +118,7 @@ Some vulnerabilities can be fixed by applying the solution that GitLab automatically generates. The following scanners are supported: - [Dependency Scanning](dependency_scanning/index.md): - Automatic Patch creation is only available for Node.JS projects managed with + Automatic Patch creation is only available for Node.js projects managed with `yarn`. #### Manually applying the suggested patch diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md index e9ae87ab44e7e7f3bbabf886fd40ad23e61521da..38542bf811d74fa926eef46aa7c389902b07abbe 100644 --- a/doc/user/application_security/security_dashboard/index.md +++ b/doc/user/application_security/security_dashboard/index.md @@ -112,7 +112,7 @@ Read more on how to [interact with the vulnerabilities](../index.md#interacting- ## Instance Security Dashboard -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6953) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6953) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.8. At the instance level, the Security Dashboard displays the vulnerabilities present in all of the projects that you have added to it. diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 381132311869bc1b1e8987618b60ac73bff40e2b..dbba71fc17b6975be0f8c959d00ee2cf3ed1824f 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -218,8 +218,11 @@ You can follow our work towards this goal in the The full contents of our `config.toml` are: +NOTE: **Note:** +Settings that are not public are shown as `X`. + ```toml -concurrent = 10 +concurrent = X check_interval = 3 [[runners]] @@ -291,8 +294,8 @@ stages: - test before_script: - - date +"%H" - - echo ${HOUR} + - Set-Variable -Name "time" -Value (date -Format "%H:%m") + - echo ${time} - echo "started by ${GITLAB_USER_NAME}" build: diff --git a/doc/user/markdown.md b/doc/user/markdown.md index 92c082e29dc8ae49a9c2ead2fb91ecfb0de7b535..7ad810317f0f9c39996c1f6243284c941c1bed12 100644 --- a/doc/user/markdown.md +++ b/doc/user/markdown.md @@ -964,7 +964,7 @@ Here's a sample audio clip: You can also use raw HTML in your Markdown, and it'll usually work pretty well. See the documentation for HTML::Pipeline's [SanitizationFilter](https://www.rubydoc.info/gems/html-pipeline/1.11.0/HTML/Pipeline/SanitizationFilter#WHITELIST-constant) -class for the list of allowed HTML tags and attributes. In addition to the default +class for the list of allowed HTML tags and attributes. In addition to the default `SanitizationFilter` whitelist, GitLab allows `span`, `abbr`, `details` and `summary` elements. ```html diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md index 58b4bf6a710b42849a500cc82f77b3bc06ff1fcc..a2944667b7ea50b506a9dadc9ef5891c876b8749 100644 --- a/doc/user/packages/npm_registry/index.md +++ b/doc/user/packages/npm_registry/index.md @@ -37,7 +37,7 @@ the [next section](#authenticating-to-the-gitlab-npm-registry). ### Installing NPM -Follow the instructions at [npmjs.com](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to download and install Node.JS and +Follow the instructions at [npmjs.com](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to download and install Node.js and NPM to your local development environment. Once installation is complete, verify you can use NPM in your terminal by diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index 95aee237bcb2d226553a41746a01020fe7c4f2e5..8f68390a270387f6e31c1cecf8c8423c45bed88f 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -349,7 +349,7 @@ The optional `runtime` parameter can refer to one of the following runtime alias After the `gitlab-ci.yml` template has been added and the `serverless.yml` file has been created, pushing a commit to your project will result in a CI pipeline -being executed which will deploy each function as a Knative service. Once the +being executed which will deploy each function as a Knative service. Once the deploy stage has finished, additional details for the function will appear under **Operations > Serverless**. diff --git a/doc/user/project/highlighting.md b/doc/user/project/highlighting.md index a715a313adf12d7a7417f347488491b30a94d389..85992e1301fadbd5f3e4c5b5ea439fcaf86cdfed 100644 --- a/doc/user/project/highlighting.md +++ b/doc/user/project/highlighting.md @@ -10,7 +10,7 @@ If GitLab is guessing wrong, you can override its choice of language using the ` When you check in and push that change, all `*.pl` files in your project will be highlighted as Prolog. -The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is: +The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is: ``` conf /Nicefile gitlab-language=ruby diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md index c990bb3cb96031523c3658956aa5208f6d224b2b..fd62165053ef147d8001d0bba503c5da3d1ec80d 100644 --- a/doc/user/project/import/bitbucket_server.md +++ b/doc/user/project/import/bitbucket_server.md @@ -48,7 +48,7 @@ The Bitbucket Server importer works as follows: When issues/pull requests are being imported, the Bitbucket importer tries to find the author's e-mail address with a confirmed e-mail address in the GitLab -user database. If no such user is available, the project creator is set as +user database. If no such user is available, the project creator is set as the author. The importer will append a note in the comment to mark the original creator. diff --git a/doc/user/project/integrations/irker.md b/doc/user/project/integrations/irker.md index 22228025969aa3d510360ae698ff5b26998d2a31..47017843233cc7c97c104c5c42b0139a559e2b12 100644 --- a/doc/user/project/integrations/irker.md +++ b/doc/user/project/integrations/irker.md @@ -47,7 +47,7 @@ Irker accepts channel names of the form `chan` and `#chan`, both for the case, `Aorimn` is treated as a nick and no more as a channel name. Irker can also join password-protected channels. Users need to append -`?key=thesecretpassword` to the chan name. When using this feature remember to +`?key=thesecretpassword` to the chan name. When using this feature remember to **not** put the `#` sign in front of the channel name; failing to do so will result on irker joining a channel literally named `#chan?key=password` henceforth leaking the channel key through the `/whois` IRC command (depending on IRC server diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index 7cefd55d9aae154d53ee2890e8e0eca47e520443..acc187d1e6b9d5dd47d0e307d57d4fe5e673b7cb 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -1364,7 +1364,7 @@ server.start ``` Pick an unused port (e.g. 8000) and start the script: `ruby print_http_body.rb -8000`. Then add your server as a webhook receiver in GitLab as +8000`. Then add your server as a webhook receiver in GitLab as `http://my.host:8000/`. When you press 'Test' in GitLab, you should see something like this in the diff --git a/doc/user/project/issues/sorting_issue_lists.md b/doc/user/project/issues/sorting_issue_lists.md index 076d9545b29fb7b8a23800224c1ed7116fc2a7c3..d52b629bfede127595c109d7bf549e69f7654611 100644 --- a/doc/user/project/issues/sorting_issue_lists.md +++ b/doc/user/project/issues/sorting_issue_lists.md @@ -19,7 +19,7 @@ order with respect to the other issues in the list. When you drag-and-drop reord an issue, its relative order value changes accordingly. In addition, any time that issue appears in a manually sorted list, -the updated relative order value will be used for the ordering. This means that +the updated relative order value will be used for the ordering. This means that if issue `A` is drag-and-drop reordered to be above issue `B` by any user in a given list inside your GitLab instance, any time those two issues are subsequently loaded in any list in the same instance (could be a different project issue list or a diff --git a/doc/user/project/members/share_project_with_groups.md b/doc/user/project/members/share_project_with_groups.md index 214937d4db29bdfb8d5b0d73606c966b4bb8337f..d0ceac3e1f3df66bb612291264d012e295026c4d 100644 --- a/doc/user/project/members/share_project_with_groups.md +++ b/doc/user/project/members/share_project_with_groups.md @@ -13,7 +13,7 @@ members. The primary mechanism to give a group of users, say 'Engineering', access to a project, say 'Project Acme', in GitLab is to make the 'Engineering' group the owner of 'Project -Acme'. But what if 'Project Acme' already belongs to another group, say 'Open Source'? +Acme'. But what if 'Project Acme' already belongs to another group, say 'Open Source'? This is where the group sharing feature can be of use. To share 'Project Acme' with the 'Engineering' group: diff --git a/doc/user/project/merge_requests/merge_request_dependencies.md b/doc/user/project/merge_requests/merge_request_dependencies.md index dceb0b473119304299103b142bdd8cf7caa300d5..66a1d2ac6af6071cd2fbe30cb713a5caa0ce5b80 100644 --- a/doc/user/project/merge_requests/merge_request_dependencies.md +++ b/doc/user/project/merge_requests/merge_request_dependencies.md @@ -4,13 +4,9 @@ type: reference, concepts # Merge Request dependencies **(PREMIUM)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in -[GitLab Premium](https://about.gitlab.com/pricing/) 12.2. -> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17291) from -"Cross-project dependencies" to "Merge Requests dependencies" in -[GitLab Premium](https://about.gitlab.com/pricing/) 12.4. -> - Intra-project MR dependencies were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16799) -in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.2. +> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17291) from "Cross-project dependencies" to "Merge Requests dependencies" in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4. +> - Intra-project MR dependencies were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16799) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4. Merge request dependencies allows a required order of merging between merge requests to be expressed. If a merge request "depends on" another, @@ -129,7 +125,7 @@ graph LR; herfriend/another-lib!1-->mycorp/awesome-project!100; ``` -What is **not** supported is a "deep", or "nested" graph of dependencies, e.g.: +What is **not** supported is a "deep", or "nested" graph of dependencies. For example: ```mermaid graph LR; diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md index 2a3d5f6c0e7b381e8dc638565dc2e2fd5ad3bf31..68b5c2651e1d461d93dcd49153cc39333a4b58ac 100644 --- a/doc/user/project/repository/gpg_signed_commits/index.md +++ b/doc/user/project/repository/gpg_signed_commits/index.md @@ -54,7 +54,7 @@ started: In some cases like Gpg4win on Windows and other macOS versions, the command here may be `gpg --gen-key`. -1. The first question is which algorithm can be used. Select the kind you want +1. The first question is which algorithm can be used. Select the kind you want or press Enter to choose the default (RSA and RSA): ```plaintext