diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-12 06:08:55 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-12 06:08:55 +0300 |
| commit | 500626a5c953ad81cfc3ed74bf0148c075617e58 (patch) | |
| tree | 554e385e0e548f15fc90388da8b73622b803d6f3 | |
| parent | b133cb2468b412683dbc5f19492d98b2ffa47d09 (diff) | |
Add latest changes from gitlab-org/gitlab@master
37 files changed, 58 insertions, 68 deletions
diff --git a/.vale.ini b/.vale.ini index 25353f97023..89a669ec7ff 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 0e13508a3cd..cbb01c41002 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 1ef903f4cf3..2ed259dad4a 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 7bebf555a6c..5fd804e11dc 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 f179885c525..a261e1e7dc6 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 601db1c790b..2dd07ab8a4e 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 018e0c4b84d..621b679de73 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 5cc93427d42..dd15b8c37b1 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 881f3297695..a516a3f56f7 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 3600c43aa4f..e8aa33b31a7 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 5617d9d43f2..133434523ec 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 1be09bfeddf..27cd0370bba 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 3ef54ca6dd3..2d53e021f81 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 c5c918e4282..10319b83233 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 ea3aeeb0f64..2afa1ba7e32 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 d3db485820f..86720aca158 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 b0b7b9526b3..8123b4ca7a7 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 cfcf11cf3c2..21de27c5249 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 bc34df4086d..07abfa4cdac 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 0841daefde3..52b92c98482 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 1e67ac88467..8f64e9207b5 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 c8ea5ee5e48..3bdda338b76 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 03bd5cb276d..07b5da1fd93 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 0567c84a66c..e1bd9ca742b 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 e9ae87ab44e..38542bf811d 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 38113231186..dbba71fc17b 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 92c082e29dc..7ad810317f0 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 58b4bf6a710..a2944667b7e 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 95aee237bcb..8f68390a270 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 a715a313adf..85992e1301f 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 c990bb3cb96..fd62165053e 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 22228025969..47017843233 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 7cefd55d9aa..acc187d1e6b 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 076d9545b29..d52b629bfed 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 214937d4db2..d0ceac3e1f3 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 dceb0b47311..66a1d2ac6af 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 2a3d5f6c0e7..68b5c2651e1 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 <kbd>Enter</kbd> to choose the default (RSA and RSA): ```plaintext |