kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-02-12 03:08:55 +00:00
parent b133cb2468
commit 500626a5c9
37 changed files with 58 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
.vale.ini
View File

@ -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

2
doc/administration/geo/replication/troubleshooting.md
View File

@ -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)

2
doc/administration/instance_limits.md
View File

@ -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.

2
doc/administration/invalidate_markdown_cache.md
View File

@ -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):

2
doc/api/README.md
View File

@ -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**.

4
doc/api/users.md
View File

@ -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

2
doc/ci/docker/using_docker_images.md
View File

@ -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.

2
doc/ci/variables/predefined_variables.md
View File

@ -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 |

8
doc/ci/yaml/README.md
View File

@ -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:

4
doc/development/api_graphql_styleguide.md
View File

@ -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

8
doc/development/emails.md
View File

@ -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:

2
doc/development/go_guide/index.md
View File

@ -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

8
doc/integration/elasticsearch.md
View File

@ -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

4
doc/integration/saml.md
View File

@ -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

2
doc/integration/vault.md
View File

@ -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.

2
doc/migrate_ci_to_ce/README.md
View File

@ -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)**.

4
doc/raketasks/backup_restore.md
View File

@ -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

2
doc/raketasks/list_repos.md
View File

@ -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).

2
doc/ssh/README.md
View File

@ -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.

2
doc/user/admin_area/settings/usage_statistics.md
View File

@ -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

2
doc/user/admin_area/settings/visibility_and_access_controls.md
View File

@ -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).

4
doc/user/application_security/container_scanning/index.md
View File

@ -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

2
doc/user/application_security/dependency_scanning/index.md
View File

@ -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

2
doc/user/application_security/index.md
View File

@ -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

2
doc/user/application_security/security_dashboard/index.md
View File

@ -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.

9
doc/user/gitlab_com/index.md
View File

@ -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:

2
doc/user/markdown.md
View File

@ -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

2
doc/user/packages/npm_registry/index.md
View File

@ -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

2
doc/user/project/clusters/serverless/index.md
View File

@ -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**.

2
doc/user/project/highlighting.md
View File

@ -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

2
doc/user/project/import/bitbucket_server.md
View File

@ -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.

2
doc/user/project/integrations/irker.md
View File

@ -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

2
doc/user/project/integrations/webhooks.md
View File

@ -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

2
doc/user/project/issues/sorting_issue_lists.md
View File

@ -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

2
doc/user/project/members/share_project_with_groups.md
View File

@ -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:

12
doc/user/project/merge_requests/merge_request_dependencies.md
View File

@ -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;

2
doc/user/project/repository/gpg_signed_commits/index.md
View File

@ -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