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-08-10 00:10:20 +00:00
parent 4c7e0ab3f1
commit 54763b367c
18 changed files with 215 additions and 211 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/README.md
View File

@ -213,7 +213,8 @@ The following documentation relates to the DevOps **Create** stage:
| Create topics - Integration and Automation | Description |
|:------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------|
| [GitLab API](api/README.md) | Integrate GitLab via a simple and powerful API. |
| [GitLab REST API](api/README.md) | Integrate with GitLab using our REST API. |
| [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
| [GitLab Integration](integration/README.md) | Integrate with multiple third-party services with GitLab to allow external issue trackers and external authentication. |
| [GitLab Webhooks](user/project/integrations/webhooks.md) | Let GitLab notify you when new code has been pushed to your project. |
| [Jira Development Panel](integration/jira_development_panel.md) **(PREMIUM)** | See GitLab information in the Jira Development Panel. |
@ -468,7 +469,8 @@ There are many ways to integrate with GitLab, including:
| Topic | Description |
|:-----------------------------------------------------------|:------------------------------------------------|
| [GitLab API](api/README.md) | Integrate GitLab via a simple and powerful API. |
| [GitLab REST API](api/README.md) | Integrate with GitLab using our REST API. |
| [GitLab GraphQL API](api/graphql/index.md) | Integrate with GitLab using our GraphQL API. |
| [Integrations and automation](#integration-and-automation) | All GitLab integration and automation options. |
<div align="right">

40
doc/ci/docker/using_docker_build.md
View File

@ -32,7 +32,7 @@ during jobs.
## Runner Configuration
There are three methods to enable the use of `docker build` and `docker run`
during jobs; each with their own tradeoffs.
during jobs, each with their own tradeoffs.
An alternative to using `docker build` is to [use kaniko](using_kaniko.md).
This avoids having to execute Runner in privileged mode.
@ -61,8 +61,8 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user.
1. Install Docker Engine on server.
For more information how to install Docker Engine on different systems
checkout the [Supported installations](https://docs.docker.com/engine/installation/).
For more information how to install Docker Engine on different systems,
check out the [Supported installations](https://docs.docker.com/engine/installation/).
1. Add `gitlab-runner` user to `docker` group:
@ -118,13 +118,13 @@ not without its own challenges:
- When using Docker-in-Docker, each job is in a clean environment without the past
history. Concurrent jobs work fine because every build gets its own
instance of Docker engine so they won't conflict with each other. But this
instance of Docker engine so they don't conflict with each other. But this
also means that jobs can be slower because there's no caching of layers.
- By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is
the recommended storage driver. See [Using the overlayfs driver](#use-the-overlayfs-driver)
for details.
- Since the `docker:19.03.12-dind` container and the Runner container don't share their
root filesystem, the job's working directory can be used as a mount point for
root file system, the job's working directory can be used as a mount point for
child containers. For example, if you have files you want to share with a
child container, you may create a subdirectory under `/builds/$CI_PROJECT_PATH`
and use it as your mount point (for a more thorough explanation, check [issue
@ -143,8 +143,8 @@ An example project using this approach can be found here: <https://gitlab.com/gi
In the examples below, we are using Docker images tags to specify a
specific version, such as `docker:19.03.12`. If tags like `docker:stable`
are used, you have no control over what version is going to be used and this
can lead to unpredictable behavior, especially when new versions are
are used, you have no control over what version is used. This can lead to
unpredictable behavior, especially when new versions are
released.
#### TLS enabled
@ -179,18 +179,18 @@ support this.
--docker-volumes "/certs/client"
```
The above command will register a new Runner to use the special
The above command registers a new Runner to use the special
`docker:19.03.12` image, which is provided by Docker. **Notice that it's
using the `privileged` mode to start the build and service
containers.** If you want to use [Docker-in-Docker](https://www.docker.com/blog/docker-can-now-run-within-docker/) mode, you always
have to use `privileged = true` in your Docker containers.
This will also mount `/certs/client` for the service and build
This also mounts `/certs/client` for the service and build
container, which is needed for the Docker client to use the
certificates inside of that directory. For more information how
Docker with TLS works check <https://hub.docker.com/_/docker/#tls>.
certificates inside of that directory. For more information on how
Docker with TLS works, check <https://hub.docker.com/_/docker/#tls>.
The above command will create a `config.toml` entry similar to this:
The above command creates a `config.toml` entry similar to this:
```toml
[[runners]]
@ -215,7 +215,7 @@ support this.
image: docker:19.03.12
variables:
# When using dind service, we need to instruct docker, to talk with
# When using dind service, we need to instruct docker to talk with
# the daemon started inside of the service. The daemon is available
# with a network connection instead of the default
# /var/run/docker.sock socket. Docker 19.03 does this automatically
@ -337,13 +337,13 @@ In order to do that, follow the steps:
--docker-volumes /var/run/docker.sock:/var/run/docker.sock
```
The above command will register a new Runner to use the special
The above command registers a new Runner to use the special
`docker:19.03.12` image which is provided by Docker. **Notice that it's using
the Docker daemon of the Runner itself, and any containers spawned by Docker
commands will be siblings of the Runner rather than children of the Runner.**
commands are siblings of the Runner rather than children of the Runner.**
This may have complications and limitations that are unsuitable for your workflow.
The above command will create a `config.toml` entry similar to this:
The above command creates a `config.toml` entry similar to this:
```toml
[[runners]]
@ -387,7 +387,7 @@ aware of the following implications:
containers.
- Concurrent jobs may not work; if your tests
create containers with specific names, they may conflict with each other.
- Sharing files and directories from the source repo into containers may not
- Sharing files and directories from the source repository into containers may not
work as expected since volume mounting is done in the context of the host
machine, not the build container. For example:
@ -397,7 +397,7 @@ aware of the following implications:
## Making Docker-in-Docker builds faster with Docker layer caching
When using Docker-in-Docker, Docker will download all layers of your image every
When using Docker-in-Docker, Docker downloads all layers of your image every
time you create a build. Recent versions of Docker (Docker 1.13 and above) can
use a pre-existing image as a cache during the `docker build` step, considerably
speeding up the build process.
@ -504,7 +504,7 @@ environment variable in the
environment = ["DOCKER_DRIVER=overlay2"]
```
If you're running multiple Runners you will have to modify all configuration files.
If you're running multiple Runners, you have to modify all configuration files.
NOTE: **Note:**
Read more about the [Runner configuration](https://docs.gitlab.com/runner/configuration/)
@ -523,7 +523,7 @@ This is a common error when you are using
[Docker in Docker](#use-docker-in-docker-workflow-with-docker-executor)
v19.03 or higher.
This occurs because Docker starts on TLS automatically, so you need to do some set up.
This occurs because Docker starts on TLS automatically, so you need to do some setup.
If:
- This is the first time setting it up, carefully read

64
doc/ci/pipelines/job_artifacts.md
View File

@ -11,7 +11,7 @@ type: reference, howto
> - Introduced in GitLab 8.2 and GitLab Runner 0.7.0.
> - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format changed to `ZIP`, and it's now possible to browse its contents, with the added ability of downloading the files separately.
> - In GitLab 8.17, builds were renamed to jobs.
> - The artifacts browser will be available only for new artifacts that are sent to GitLab using GitLab Runner version 1.0 and up. It won't be possible to browse old artifacts already uploaded to GitLab.
> - The artifacts browser is available only for new artifacts that are sent to GitLab using GitLab Runner version 1.0 and up. You cannot browse old artifacts already uploaded to GitLab.
Job artifacts are a list of files and directories created by a job
once it finishes. This feature is [enabled by default](../../administration/job_artifacts.md) in all
@ -42,9 +42,9 @@ the latex source file `mycv.tex`. We then define the `artifacts` paths which in
turn are defined with the `paths` keyword. All paths to files and directories
are relative to the repository that was cloned during the build.
The artifacts will be uploaded when the job succeeds by default, but can be set to upload
when the job fails, or always, if the [`artifacts:when`](../yaml/README.md#artifactswhen)
parameter is used. These uploaded artifacts will be kept in GitLab for 1 week as defined
By default, the artifacts upload when the job succeeds. You can also set artifacts to upload
when the job fails, or always, by using [`artifacts:when`](../yaml/README.md#artifactswhen)
parameter. GitLab keeps these uploaded artifacts for 1 week, as defined
by the `expire_in` definition. You can keep the artifacts from expiring
via the [web interface](#browsing-artifacts). If the expiry time is not defined, it defaults
to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only).
@ -94,13 +94,12 @@ rspec:
junit: rspec.xml
```
The collected JUnit reports will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
The collected JUnit reports upload to GitLab as an artifact and display in merge requests.
NOTE: **Note:**
In case the JUnit tool you use exports to multiple XML files, you can specify
multiple test report paths within a single job and they will be automatically
concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`),
If the JUnit tool you use exports to multiple XML files, specify
multiple test report paths within a single job to
concatenate them into a single file. Use a filename pattern (`junit: rspec-*.xml`),
an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a
combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`).
@ -130,8 +129,8 @@ There are a couple of exceptions to the [original dotenv rules](https://github.c
> - Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above.
The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md).
The collected Cobertura coverage reports will be uploaded to GitLab as an artifact
and will be automatically shown in merge requests.
The collected Cobertura coverage reports upload to GitLab as an artifact
and display in merge requests.
Cobertura was originally developed for Java, but there are many
third party ports for other languages like JavaScript, Python, Ruby, and so on.
@ -142,7 +141,7 @@ third party ports for other languages like JavaScript, Python, Ruby, and so on.
> - Requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 and above.
The `terraform` report obtains a Terraform `tfplan.json` file. [JQ processing required to remove credentials](../../user/infrastructure/index.md#output-terraform-plan-information-into-a-merge-request). The collected Terraform
plan report will be uploaded to GitLab as an artifact and will be automatically shown
plan report uploads to GitLab as an artifact and displays
in merge requests. For more information, see
[Output `terraform plan` information into a merge request](../../user/infrastructure/index.md#output-terraform-plan-information-into-a-merge-request).
@ -155,8 +154,7 @@ in merge requests. For more information, see
The `codequality` report collects [CodeQuality issues](../../user/project/merge_requests/code_quality.md)
as artifacts.
The collected Code Quality report will be uploaded to GitLab as an artifact and will
be summarized in merge requests.
The collected Code Quality report uploads to GitLab as an artifact and is summarized in merge requests.
#### `artifacts:reports:sast` **(ULTIMATE)**
@ -166,8 +164,8 @@ be summarized in merge requests.
The `sast` report collects [SAST vulnerabilities](../../user/application_security/sast/index.md)
as artifacts.
The collected SAST report will be uploaded to GitLab as an artifact and will be summarized
in the merge requests and pipeline view. It's also used to provide data for security
The collected SAST report uploads to GitLab as an artifact and is summarized
in merge requests and the pipeline view. It's also used to provide data for security
dashboards.
#### `artifacts:reports:secret_detection` **(ULTIMATE)**
@ -190,8 +188,7 @@ dashboards.
The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](../../user/application_security/dependency_scanning/index.md)
as artifacts.
The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will
be summarized in the merge requests and pipeline view. It's also used to provide data for security
The collected Dependency Scanning report uploads to GitLab as an artifact and is summarized in merge requests and the pipeline view. It's also used to provide data for security
dashboards.
#### `artifacts:reports:container_scanning` **(ULTIMATE)**
@ -202,8 +199,8 @@ dashboards.
The `container_scanning` report collects [Container Scanning vulnerabilities](../../user/application_security/container_scanning/index.md)
as artifacts.
The collected Container Scanning report will be uploaded to GitLab as an artifact and will
be summarized in the merge requests and pipeline view. It's also used to provide data for security
The collected Container Scanning report uploads to GitLab as an artifact and
is summarized in merge requests and the pipeline view. It's also used to provide data for security
dashboards.
#### `artifacts:reports:dast` **(ULTIMATE)**
@ -214,8 +211,7 @@ dashboards.
The `dast` report collects [DAST vulnerabilities](../../user/application_security/dast/index.md)
as artifacts.
The collected DAST report will be uploaded to GitLab as an artifact and will
be summarized in the merge requests and pipeline view. It's also used to provide data for security
The collected DAST report uploads to GitLab as an artifact and is summarized in merge requests and the pipeline view. It's also used to provide data for security
dashboards.
#### `artifacts:reports:license_management` **(ULTIMATE)**
@ -231,8 +227,7 @@ introduced in GitLab 12.8.
The `license_management` report collects [Licenses](../../user/compliance/license_compliance/index.md)
as artifacts.
The collected License Compliance report will be uploaded to GitLab as an artifact and will
be summarized in the merge requests and pipeline view. It's also used to provide data for security
The collected License Compliance report uploads to GitLab as an artifact and is summarized in merge requests and the pipeline view. It's also used to provide data for security
dashboards.
#### `artifacts:reports:license_scanning` **(ULTIMATE)**
@ -243,8 +238,7 @@ dashboards.
The `license_scanning` report collects [Licenses](../../user/compliance/license_compliance/index.md)
as artifacts.
The License Compliance report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
The License Compliance report uploads to GitLab as an artifact and displays automatically in merge requests and the pipeline view, and provide data for security
dashboards.
#### `artifacts:reports:performance` **(PREMIUM)**
@ -255,8 +249,7 @@ dashboards.
The `performance` report collects [Browser Performance Testing metrics](../../user/project/merge_requests/browser_performance_testing.md)
as artifacts.
The collected Browser Performance report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
The collected Browser Performance report uploads to GitLab as an artifact and displays in merge requests.
#### `artifacts:reports:load_performance` **(PREMIUM)**
@ -276,8 +269,7 @@ shown in merge requests automatically.
The `metrics` report collects [Metrics](../metrics_reports.md)
as artifacts.
The collected Metrics report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
The collected Metrics report uploads to GitLab as an artifact and displays in merge requests.
#### `artifacts:reports:requirements` **(ULTIMATE)**
@ -286,8 +278,8 @@ be automatically shown in merge requests.
The `requirements` report collects `requirements.json` files as artifacts.
The collected Requirements report will be uploaded to GitLab as an artifact and
existing [requirements](../../user/project/requirements/index.md) will be
The collected Requirements report uploads to GitLab as an artifact and
existing [requirements](../../user/project/requirements/index.md) are
marked as Satisfied.
## Browsing artifacts
@ -348,10 +340,8 @@ so you can use it for scripting purposes.
NOTE: **Note:**
The latest artifacts are created by jobs in the **most recent** successful pipeline
for the specific ref. If you run two types of pipelines for the same ref, the latest
artifact will be determined by timing. For example, if a branch pipeline created
by merging a merge request runs at the same time as a scheduled pipeline, the
latest artifact will be from the pipeline that completed most recently.
for the specific ref. If you run two types of pipelines for the same ref, timing determines the latest
artifact. For example, if a merge request creates a branch pipeline at the same time as a scheduled pipeline, the pipeline that completed most recently creates the latest artifact.
Artifacts for other pipelines can be accessed with direct access to them.
@ -425,7 +415,7 @@ information in the UI.
DANGER: **Danger:**
This is a destructive action that leads to data loss. Use with caution.
You can erase a single job via the UI, which will also remove the job's
You can erase a single job via the UI, which also removes the job's
artifacts and trace, if you are:
- The owner of the job.

9
doc/ci/runners/README.md
View File

@ -7,7 +7,7 @@ type: reference
# Configuring GitLab Runners
<!-- This topic contains several commented-out sections that were accidentally added in 13.2.-->
<!-- The commented-out sections will be added back in 13.3.-->
<!-- The commented-out sections are added back in 13.3.-->
In GitLab CI/CD, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md).
A GitLab Runner is a lightweight, highly-scalable agent that picks up a CI job through
@ -266,7 +266,7 @@ if smaller than the [project defined timeout](../pipelines/settings.md#timeout),
This feature can be used to prevent your shared Runner from being overwhelmed
by a project that has jobs with a long timeout (for example, one week).
When not configured, Runners will not override the project timeout.
When not configured, Runners do not override the project timeout.
How this feature works:
@ -329,8 +329,7 @@ To protect or unprotect a Runner:
Whenever a project is forked, it copies the settings of the jobs that relate
to it. This means that if you have shared Runners set up for a project and
someone forks that project, the shared Runners will also serve jobs of this
project.
someone forks that project, the shared Runners serve jobs of this project.
### Attack vectors in Runners
@ -353,7 +352,7 @@ To reset the token:
1. After the page is refreshed, expand the **Runners settings** section
and check the registration token - it should be changed.
From now on the old token is no longer valid and will not register
From now on the old token is no longer valid and does not register
any new Runners to the project. If you are using any tools to provision and
register new Runners, the tokens used in those tools should be updated to reflect the
value of the new token.

36
doc/install/installation.md
View File

@ -28,12 +28,12 @@ following the
Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
One reason the Omnibus package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
On heavily used GitLab instances the memory usage of the Sidekiq background worker will grow over time.
On heavily used GitLab instances the memory usage of the Sidekiq background worker grows over time.
Omnibus packages solve this by [letting the Sidekiq terminate gracefully](../administration/operations/sidekiq_memory_killer.md) if it uses too much memory.
After this termination runit will detect Sidekiq is not running and will start it.
After this termination runit detects Sidekiq is not running and starts it.
Since installations from source don't use runit for process supervision, Sidekiq
can't be terminated and its memory usage will grow over time.
can't be terminated and its memory usage grows over time.
## Select a version to install
@ -44,7 +44,7 @@ If the highest number stable branch is unclear, check the [GitLab blog](https://
## GitLab directory structure
This is the main directory structure you will end up with following the instructions
This is the main directory structure you end up with following the instructions
of this page:
```plaintext
@ -99,7 +99,7 @@ apt-get install sudo -y
```
NOTE: **Note:**
During this installation, some files will need to be edited manually. If you are familiar with vim, set it as default editor with the commands below. If you are not familiar with vim, skip this and keep using the default editor.
During this installation, some files need to be edited manually. If you are familiar with vim, set it as default editor with the commands below. If you are not familiar with vim, skip this and keep using the default editor.
```shell
# Install vim and set as default editor
@ -286,7 +286,7 @@ requirements for these are:
In many distros,
the versions provided by the official package repositories are out of date, so
we'll need to install through the following commands:
we need to install through the following commands:
```shell
# install node v12.x
@ -366,7 +366,7 @@ Starting from GitLab 12.1, only PostgreSQL is supported. Since GitLab 13.0, we r
AND installed_version IS NOT NULL;
```
If the extension is enabled this will produce the following output:
If the extension is enabled this produces the following output:
```plaintext
enabled
@ -384,7 +384,7 @@ Starting from GitLab 12.1, only PostgreSQL is supported. Since GitLab 13.0, we r
AND installed_version IS NOT NULL;
```
If the extension is enabled this will produce the following output:
If the extension is enabled this produces the following output:
```plaintext
enabled
@ -616,12 +616,12 @@ NOTE: **Note:**
If you want to use HTTPS, see [Using HTTPS](#using-https) for the additional steps.
NOTE: **Note:**
Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1 hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check will fail with `Check GitLab API access: FAILED. code: 401` and pushing commits will be rejected with `[remote rejected] master -> master (hook declined)`.
Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1 hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check fails with `Check GitLab API access: FAILED. code: 401` and pushing commits are rejected with `[remote rejected] master -> master (hook declined)`.
### Install GitLab Workhorse
GitLab-Workhorse uses [GNU Make](https://www.gnu.org/software/make/). The
following command-line will install GitLab-Workhorse in `/home/git/gitlab-workhorse`
following command-line installs GitLab-Workhorse in `/home/git/gitlab-workhorse`
which is the recommended location.
```shell
@ -637,7 +637,7 @@ sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workh
### Install GitLab-Elasticsearch-indexer on Enterprise Edition
GitLab-Elasticsearch-Indexer uses [GNU Make](https://www.gnu.org/software/make/). The
following command-line will install GitLab-Elasticsearch-Indexer in `/home/git/gitlab-elasticsearch-indexer`
following command-line installs GitLab-Elasticsearch-Indexer in `/home/git/gitlab-elasticsearch-indexer`
which is the recommended location.
```shell
@ -650,15 +650,15 @@ You can specify a different Git repository by providing it as an extra parameter
sudo -u git -H bundle exec rake "gitlab:indexer:install[/home/git/gitlab-elasticsearch-indexer,https://example.com/gitlab-elasticsearch-indexer.git]" RAILS_ENV=production
```
The source code will first be fetched to the path specified by the first parameter. Then a binary will be built under its `bin` directory.
You will then need to update `gitlab.yml`'s `production -> elasticsearch -> indexer_path` setting to point to that binary.
The source code first is fetched to the path specified by the first parameter. Then a binary is built under its `bin` directory.
You then need to update `gitlab.yml`'s `production -> elasticsearch -> indexer_path` setting to point to that binary.
NOTE: **Note:**
Elasticsearch is a feature of GitLab Enterprise Edition and isn't included in GitLab Community Edition.
### Install GitLab Pages
GitLab Pages uses [GNU Make](https://www.gnu.org/software/make/). This step is optional and only needed if you wish to host static sites from within GitLab. The following commands will install GitLab Pages in `/home/git/gitlab-pages`. For additional setup steps, consult the [administration guide](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/pages/source.md) for your version of GitLab as the GitLab Pages daemon can be run several different ways.
GitLab Pages uses [GNU Make](https://www.gnu.org/software/make/). This step is optional and only needed if you wish to host static sites from within GitLab. The following commands install GitLab Pages in `/home/git/gitlab-pages`. For additional setup steps, consult the [administration guide](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/pages/source.md) for your version of GitLab as the GitLab Pages daemon can be run several different ways.
```shell
cd /home/git
@ -737,7 +737,7 @@ Otherwise, your secrets are exposed if one of your backups is compromised.
### Install Init Script
Download the init script (will be `/etc/init.d/gitlab`):
Download the init script (is `/etc/init.d/gitlab`):
```shell
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
@ -749,7 +749,7 @@ And if you are installing with a non-default folder or user copy and edit the de
sudo cp lib/support/init.d/gitlab.default.example /etc/default/gitlab
```
If you installed GitLab in another directory or as a user other than the default, you should change these settings in `/etc/default/gitlab`. Do not edit `/etc/init.d/gitlab` as it will be changed on upgrade.
If you installed GitLab in another directory or as a user other than the default, you should change these settings in `/etc/default/gitlab`. Do not edit `/etc/init.d/gitlab` as it is changed on upgrade.
Make GitLab start on boot:
@ -946,7 +946,7 @@ See the [GitLab Runner section](https://about.gitlab.com/stages-devops-lifecycle
### Adding your Trusted Proxies
If you are using a reverse proxy on a separate machine, you may want to add the
proxy to the trusted proxies list. Otherwise users will appear signed in from the
proxy to the trusted proxies list. Otherwise users appear signed in from the
proxy's IP address.
You can add trusted proxies in `config/gitlab.yml` by customizing the `trusted_proxies`
@ -1018,7 +1018,7 @@ If you want to switch back to Unicorn, follow these steps:
### Using Sidekiq instead of Sidekiq Cluster
As of GitLab 12.10, Source installations are using `bin/sidekiq-cluster` for managing Sidekiq processes.
Using Sidekiq directly will still be supported until 14.0. So if you're experiencing issues, please:
Using Sidekiq directly is still supported until 14.0. So if you're experiencing issues, please:
1. Edit the system `init.d` script to remove the `SIDEKIQ_WORKERS` flag. If you have `/etc/default/gitlab`, then you should edit it instead.
1. Restart GitLab.

44
doc/user/packages/conan_repository/index.md
View File

@ -20,7 +20,7 @@ NOTE: **Note:**
This option is available only if your GitLab administrator has
[enabled support for the Conan Repository](../../../administration/packages/index.md).
After the Conan Repository is enabled, it will be available for all new projects
After the Conan Repository is enabled, it's available for all new projects
by default. To enable it for existing projects, or if you want to disable it:
1. Navigate to your project's **Settings > General > Visibility, project features, permissions**.
@ -31,7 +31,7 @@ You should then be able to see the **Packages & Registries** section on the left
## Getting started
This section will cover installing Conan and building a package for your C/C++ project. This is a quickstart if you are new
This section covers installing Conan and building a package for your C/C++ project. This is a quickstart if you're new
to Conan. If you already are using Conan and understand how to build your own packages, move on to the [next section](#adding-the-gitlab-package-registry-as-a-conan-remote).
### Installing Conan
@ -66,10 +66,10 @@ instructions at [cmake.org](https://cmake.org/install/) for your operating syste
### Creating a project
Understanding what is needed to create a valid and compilable C++ project is out of the scope of this guide, but if you are new to C++ and want to try out the GitLab
Understanding what is needed to create a valid and compilable C++ project is out of the scope of this guide, but if you're new to C++ and want to try out the GitLab
package registry, Conan.io has a great [hello world starter project](https://github.com/conan-io/hello) that you can clone to get started.
Clone the repo and it can be used for the rest of the tutorial if you don't have your own C++ project.
Clone the repository and it can be used for the rest of the tutorial if you don't have your own C++ project.
### Building a package
@ -80,7 +80,7 @@ package name and version:
conan new Hello/0.1 -t
```
Next, you will create a package for that recipe by running `conan create` providing the Conan user and channel:
Next, create a package for that recipe by running `conan create` providing the Conan user and channel:
```shell
conan create . my-org+my-group+my-project/beta
@ -91,11 +91,11 @@ Current [naming restrictions](#package-recipe-naming-convention) require you to
The example above would create a package belonging to this project: `https://gitlab.com/my-org/my-group/my-project` with a channel of `beta`.
These two example commands will generate a final package with the recipe `Hello/0.1@my-org+my-group+my-project/beta`.
These two example commands generate a final package with the recipe `Hello/0.1@my-org+my-group+my-project/beta`.
For more advanced details on creating and managing your packages, refer to the [Conan docs](https://docs.conan.io/en/latest/creating_packages.html).
You are now ready to upload your package to the GitLab registry. To get started, first you will need to set GitLab as a remote, then you will need to add a Conan user for that remote to authenticate your requests.
You are now ready to upload your package to the GitLab registry. To get started, first you need to set GitLab as a remote. Then you need to add a Conan user for that remote to authenticate your requests.
## Adding the GitLab Package Registry as a Conan remote
@ -115,7 +115,7 @@ conan search Hello* --all --remote=gitlab
## Authenticating to the GitLab Conan Repository
You will need a personal access token or deploy token.
You need a personal access token or deploy token.
For repository authentication:
@ -124,7 +124,7 @@ For repository authentication:
### Adding a Conan user to the GitLab remote
Once you have a personal access token and have [set your Conan remote](#adding-the-gitlab-package-registry-as-a-conan-remote), you can associate the token with the remote so you do not have to explicitly add them to each Conan command you run:
Once you have a personal access token and have [set your Conan remote](#adding-the-gitlab-package-registry-as-a-conan-remote), you can associate the token with the remote so you don't have to explicitly add them to each Conan command you run:
```shell
conan user <gitlab_username or deploy_token_username> -r gitlab -p <personal_access_token or deploy_token>
@ -133,10 +133,10 @@ conan user <gitlab_username or deploy_token_username> -r gitlab -p <personal_acc
NOTE: **Note:**
If you named your remote something other than `gitlab`, your remote name should be used in this command instead of `gitlab`.
From now on, when you run commands using `--remote=gitlab`, your username and password will automatically be included in the requests.
From now on, when you run commands using `--remote=gitlab`, your username and password is automatically included in the requests.
NOTE: **Note:**
The personal access token is not stored locally at any moment. Conan uses JWT, so when you run this command, Conan will request an expirable token from GitLab using your token. The JWT does expire on a regular basis, so you will need to re-enter your personal access token when that happens.
The personal access token is not stored locally at any moment. Conan uses JSON Web Tokens (JWT), so when you run this command, Conan requests an expirable token from GitLab using your token. The JWT does expire on a regular basis, so you need to re-enter your personal access token when that happens.
Alternatively, you could explicitly include your credentials in any given command.
For example:
@ -157,7 +157,7 @@ NOTE: **Note:**
The package recipe does include the version, so setting the default remote for `Hello/0.1@user/channel` will not work for `Hello/0.2@user/channel`.
This functionality is best suited for when you want to consume or install packages from the GitLab registry without having to specify a remote.
The rest of the example commands in this documentation assume that you have added a Conan user with your credentials to the `gitlab` remote and will not include the explicit credentials or remote option, but be aware that any of the commands could be run without having added a user or default remote:
The rest of the example commands in this documentation assume that you've added a Conan user with your credentials to the `gitlab` remote and will not include the explicit credentials or remote option. With that said, be aware that any of the commands could be run without having added a user or default remote:
```shell
`CONAN_LOGIN_USERNAME=<gitlab_username or deploy_token_username> CONAN_PASSWORD=<personal_access_token or deploy_token> <conan command> --remote=gitlab
@ -167,7 +167,7 @@ The rest of the example commands in this documentation assume that you have adde
First you need to [create your Conan package locally](https://docs.conan.io/en/latest/creating_packages/getting_started.html). In order to work with the GitLab Package Registry, a specific [naming convention](#package-recipe-naming-convention) must be followed.
Ensure you have a project created on GitLab and that the personal access token you are using has the correct permissions for write access to the container registry by selecting the `api` [scope](../../../user/profile/personal_access_tokens.md#limiting-scopes-of-a-personal-access-token).
Ensure you have a project created on GitLab and that the personal access token you're using has the correct permissions for write access to the container registry by selecting the `api` [scope](../../../user/profile/personal_access_tokens.md#limiting-scopes-of-a-personal-access-token).
You can upload your package to the GitLab Package Registry using the `conan upload` command:
@ -181,7 +181,7 @@ Standard Conan recipe convention looks like `package_name/version@user/channel`.
**The recipe user must be the `+` separated project path**. The package
name may be anything, but it is preferred that the project name be used unless
it is not possible due to a naming collision. For example:
it's not possible due to a naming collision. For example:
| Project | Package | Supported |
| ---------------------------------- | ----------------------------------------------- | --------- |
@ -191,7 +191,7 @@ it is not possible due to a naming collision. For example:
| `gitlab-org/gitlab-ce` | `my-package/1.0.0@foo/stable` | No |
NOTE: **Note:**
A future iteration will extend support to [project and group level](https://gitlab.com/gitlab-org/gitlab/-/issues/11679) remotes which will allow for more flexible naming conventions.
A future iteration will extend support to [project and group level](https://gitlab.com/gitlab-org/gitlab/-/issues/11679) remotes which allows for more flexible naming conventions.
## Installing a package
@ -223,7 +223,7 @@ conan install ..
```
NOTE: **Note:**
If you are trying to install the package you just created in this tutorial, not much will happen since that package
If you're trying to install the package you just created in this tutorial, not much will happen since that package
already exists on your local machine.
## Removing a package
@ -236,11 +236,11 @@ There are two ways to remove a Conan package from the GitLab Package Registry.
conan remove Hello/0.2@user/channel --remote=gitlab
```
You need to explicitly include the remote in this command, otherwise the package will only be removed from your
You need to explicitly include the remote in this command, otherwise the package is only removed from your
local system cache.
NOTE: **Note:**
This command will remove all recipe and binary package files from the Package Registry.
This command removes all recipe and binary package files from the Package Registry.
- **GitLab project interface**: in the packages view of your project page, you can delete packages by clicking the red trash icons.
@ -248,7 +248,7 @@ There are two ways to remove a Conan package from the GitLab Package Registry.
The `conan search` command can be run searching by full or partial package name, or by exact recipe.
To search using a partial name, use the wildcard symbol `*`, which should be placed at the end of your search (e.g., `my-packa*`):
To search using a partial name, use the wildcard symbol `*`, which should be placed at the end of your search (for example, `my-packa*`):
```shell
conan search Hello --all --remote=gitlab
@ -256,11 +256,11 @@ conan search He* --all --remote=gitlab
conan search Hello/0.1@my-group+my-project/beta --all --remote=gitlab
```
The scope of your search will include all projects you have permission to access, this includes your private projects as well as all public projects.
The scope of your search includes all projects you have permission to access, this includes your private projects as well as all public projects.
## Fetching Conan package information from the GitLab Package Registry
The `conan info` command will return information about a given package:
The `conan info` command returns information about a given package:
```shell
conan info Hello/0.1@my-group+my-project/beta
@ -283,7 +283,7 @@ The GitLab Conan repository supports the following Conan CLI commands:
To work with Conan commands within [GitLab CI/CD](./../../../ci/README.md), you can use
`CI_JOB_TOKEN` in place of the personal access token in your commands.
It is easiest to provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each
It's easiest to provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each
Conan command in your `.gitlab-ci.yml` file. For example:
```yaml

63
doc/user/packages/container_registry/index.md
View File

@ -49,7 +49,7 @@ project:
1. Expand the **Visibility, project features, permissions** section
and enable the **Container Registry** feature on your project. For new
projects this might be enabled by default. For existing projects
(prior GitLab 8.8), you will have to explicitly enable it.
(prior GitLab 8.8), enable it explicitly.
1. Press **Save changes** for the changes to take effect. You should now be able
to see the **Packages & Registries > Container Registry** link in the sidebar.
@ -64,14 +64,14 @@ Navigate to your project's **{package}** **Packages & Registries > Container Reg
![Container Registry project repositories](img/container_registry_repositories_with_quickstart_v13_1.png)
This view will:
This view allows you to:
- Show all the image repositories that belong to the project.
- Allow you to filter image repositories by their name.
- Allow you to [delete](#delete-images-from-within-gitlab) one or more image repository.
- Allow you to navigate to the image repository details page.
- Filter image repositories by their name.
- [Delete](#delete-images-from-within-gitlab) one or more image repository.
- Navigate to the image repository details page.
- Show a **Quick start** dropdown with the most common commands to log in, build and push
- Optionally, a banner will be visible if the [cleanup policy](#cleanup-policy) is enabled for this project.
- Show a banner if the optional [cleanup policy](#cleanup-policy) is enabled for this project.
### Control Container Registry for your group
@ -79,15 +79,15 @@ Navigate to your groups's **{package}** **Packages & Registries > Container Regi
![Container Registry group repositories](img/container_registry_group_repositories_v13_1.png)
This view will:
This view allows you to:
- Show all the image repositories of the projects that belong to this group.
- Allow to [delete](#delete-images-from-within-gitlab) one or more image repositories.
- Allow to navigate to a specific image repository details page.
- [Delete](#delete-images-from-within-gitlab) one or more image repositories.
- Navigate to a specific image repository details page.
### Image Repository details page
Clicking on the name of any image repository will navigate to the details.
Clicking on the name of any image repository navigates to the details.
![Container Registry project repository details](img/container_registry_repository_details_v13.0.png)
@ -133,7 +133,7 @@ enabled in your account, you need to pass a
[personal access token](../../profile/personal_access_tokens.md) instead
of your password in order to login to GitLab's Container Registry.
If a project is private, credentials will need to be provided for authorization.
If a project is private, credentials are needed for authorization.
There are two ways to do this:
- By using a [personal access token](../../profile/personal_access_tokens.md).
@ -158,7 +158,7 @@ docker build -t registry.example.com/group/project/image .
docker push registry.example.com/group/project/image
```
Your image will be named after the following scheme:
Your image is named after the following scheme:
```plaintext
<registry URL>/<namespace>/<project>/<image>
@ -175,8 +175,8 @@ registry.example.com/group/project/my/image:rc1
## Build and push images using GitLab CI/CD
While you can build and push your images from your local machine, the true
power of the Container Registry comes when you combine it with GitLab CI/CD.
While you can build and push your images from your local machine, take
full advantage of the Container Registry by combining it with GitLab CI/CD.
You can then create workflows and automate any processes that involve testing,
building, and eventually deploying your project from the Docker image you
created.
@ -192,7 +192,7 @@ Before diving into the details, some things you should be aware of:
- Doing an explicit `docker pull` before each `docker run` fetches
the latest image that was just built. This is especially important if you are
using multiple Runners that cache images locally. Using the Git SHA in your
image tag makes this less necessary since each job will be unique and you
image tag makes this less necessary since each job is unique and you
shouldn't ever have a stale image. However, it's still possible to have a
stale image if you re-build a given commit after a dependency has changed.
- You don't want to build directly to `latest` tag in case there are multiple jobs
@ -235,7 +235,7 @@ For private and internal projects:
[special deploy token](../../project/deploy_tokens/index.md#gitlab-deploy-token)
with your private projects. It provides read-only (pull) access to the Registry.
Once created, you can use the special environment variables, and GitLab CI/CD
will fill them in for you. You can use the following example as-is:
fills them in for you. You can use the following example as-is:
```shell
docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
@ -276,7 +276,7 @@ build:
Here, `$CI_REGISTRY_IMAGE` would be resolved to the address of the registry tied
to this project. Since `$CI_COMMIT_REF_NAME` resolves to the branch or tag name,
and your branch-name can contain forward slashes (e.g., feature/my-feature), it is
and your branch name can contain forward slashes (for example, `feature/my-feature`), it is
safer to use `$CI_COMMIT_REF_SLUG` as the image tag. This is due to that image tags
cannot contain forward slashes. We also declare our own variable, `$IMAGE_TAG`,
combining the two to save us some typing in the `script` section.
@ -352,8 +352,8 @@ is set to `always`.
### Using a Docker-in-Docker image from your Container Registry
If you want to use your own Docker images for Docker-in-Docker, there are a few
things you need to do in addition to the steps in the
To use your own Docker images for Docker-in-Docker, follow these steps
in addition to the steps in the
[Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor) section:
1. Update the `image` and `service` to point to your registry.
@ -373,8 +373,8 @@ Below is an example of what your `.gitlab-ci.yml` should look like:
- docker run my-docker-image /script/to/run/tests
```
If you forget to set the service alias, the `docker:19.03.12` image won't find the
`dind` service, and an error like the following will be thrown:
If you forget to set the service alias, the `docker:19.03.12` image is unable to find the
`dind` service, and an error like the following is thrown:
```plaintext
error during connect: Get http://docker:2376/v1.39/info: dial tcp: lookup docker on 192.168.0.1:53: no such host
@ -552,8 +552,8 @@ To create a cleanup policy in the UI:
| **Expiration interval** | How long tags are exempt from being deleted. |
| **Expiration schedule** | How often the policy should run. |
| **Number of tags to retain** | How many tags to _always_ keep for each image. |
| **Tags with names matching this regex pattern will expire:** | The regex pattern that determines which tags to remove. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
| **Tags with names matching this regex pattern will be preserved:** | The regex pattern that determines which tags to preserve. The `latest` tag is always preserved. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
| **Tags with names matching this regex pattern expire:** | The regex pattern that determines which tags to remove. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
| **Tags with names matching this regex pattern are preserved:** | The regex pattern that determines which tags to preserve. The `latest` tag is always preserved. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
1. Click **Set cleanup policy**.
@ -609,11 +609,12 @@ See the API documentation for further details: [Edit project](../../../api/proje
### Use with external container registries
When using an [external container registry](./../../../administration/packages/container_registry.md#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint),
running a cleanup policy on a project may have some performance risks. If a project is going to run
a policy that will remove large quantities of tags (in the thousands), the GitLab background jobs that
run the policy may get backed up or fail completely. It is recommended you only enable container cleanup
policies for projects that were created before GitLab 12.8 if you are confident the amount of tags
being cleaned up will be minimal.
running a cleanup policy on a project may have some performance risks.
If a project runs a policy to remove thousands of tags
the GitLab background jobs may get backed up or fail completely.
It is recommended you only enable container cleanup
policies for projects that were created before GitLab 12.8 if you are confident the number of tags
being cleaned up is minimal.
### Troubleshooting cleanup policies
@ -640,9 +641,9 @@ You can read more about the above challenges [here](https://gitlab.com/gitlab-or
- Moving or renaming existing Container Registry repositories is not supported
once you have pushed images, because the images are signed, and the
signature includes the repository name. To move or rename a repository with a
Container Registry, you will have to delete all existing images.
Container Registry, you must delete all existing images.
- Prior to GitLab 12.10, any tags that use the same image ID as the `latest` tag
will not be deleted by the cleanup policy.
are not deleted by the cleanup policy.
## Troubleshooting the GitLab Container Registry
@ -661,7 +662,7 @@ name.
### Troubleshoot as a GitLab server admin
Troubleshooting the GitLab Container Registry, most of the times, requires
administration access to the GitLab server.
administrator access to the GitLab server.
[Read how to troubleshoot the Container Registry](../../../administration/packages/container_registry.md#troubleshooting).

16
doc/user/packages/pypi_repository/index.md
View File

@ -18,7 +18,7 @@ The GitLab PyPi Repository works with:
## Setting up your development environment
You will need a recent version of [pip](https://pypi.org/project/pip/) and [twine](https://pypi.org/project/twine/).
You need a recent version of [pip](https://pypi.org/project/pip/) and [twine](https://pypi.org/project/twine/).
## Enabling the PyPi Repository
@ -26,7 +26,7 @@ NOTE: **Note:**
This option is available only if your GitLab administrator has
[enabled support for the Package Registry](../../../administration/packages/index.md).
After the PyPi Repository is enabled, it will be available for all new projects
After the PyPi Repository is enabled, it is available for all new projects
by default. To enable it for existing projects, or if you want to disable it:
1. Navigate to your project's **Settings > General > Visibility, project features, permissions**.
@ -37,7 +37,7 @@ You should then be able to see the **Packages & Registries** section on the left
## Getting started
This section will cover creating a new example PyPi package to upload. This is a
This section covers creating a new example PyPi package to upload. This is a
quickstart to test out the **GitLab PyPi Registry**. If you already understand how
to build and publish your own packages, move on to the [next section](#adding-the-gitlab-pypi-repository-as-a-source).
@ -159,7 +159,7 @@ Package Registry**. Before we do so, we next need to set up authentication.
### Authenticating with a personal access token
You will need the following:
You need the following:
- A personal access token. You can generate a [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `api` for repository authentication.
- A suitable name for your source.
@ -180,7 +180,7 @@ password = <your personal access token>
### Authenticating with a deploy token
You will need the following:
You need the following:
- A deploy token. You can generate a [deploy token](./../../project/deploy_tokens/index.md) with the `read_package_registry` and/or `write_package_registry` scopes for repository authentication.
- A suitable name for your source.
@ -205,7 +205,7 @@ When uploading packages, note that:
- The maximum allowed size is 50 Megabytes.
- If you upload the same package with the same version multiple times, each consecutive upload
is saved as a separate file. When installing a package, GitLab will serve the most recent file.
is saved as a separate file. When installing a package, GitLab serves the most recent file.
### Upload packages with Twine
@ -229,8 +229,8 @@ Uploading mypypipackage-0.0.1.tar.gz
This indicates that the package was uploaded successfully. You can then navigate
to your project's **Packages & Registries** page and see the uploaded packages.
If you did not follow the guide above, the you'll need to ensure your package
has been properly built and you [created a PyPi package with setuptools](https://packaging.python.org/tutorials/packaging-projects/).
If you did not follow the guide above, then you need to ensure your package
has been properly built and you [created a PyPi package with `setuptools`](https://packaging.python.org/tutorials/packaging-projects/).
You can then upload your package using the following command:

33
doc/user/permissions.md
View File

@ -8,15 +8,14 @@ Users have different abilities depending on the access level they have in a
particular group or project. If a user is both in a project's group and the
project itself, the highest permission level is used.
On public and internal projects the Guest role is not enforced. All users will
be able to:
On public and internal projects the Guest role is not enforced. All users can:
- Create issues.
- Leave comments.
- Clone or download the project code.
When a member leaves a team's project, all the assigned [Issues](project/issues/index.md) and [Merge Requests](project/merge_requests/index.md)
will be unassigned automatically.
are unassigned automatically.
GitLab [administrators](../administration/index.md) receive all permissions.
@ -39,7 +38,7 @@ NOTE: **Note:**
In GitLab 11.0, the Master role was renamed to Maintainer.
While Maintainer is the highest project-level role, some actions can only be performed by a personal namespace or group owner,
or an instance admin, who receives all permissions. For more information, see [projects members documentation](project/members/index.md).
or an instance administrator, who receives all permissions. For more information, see [projects members documentation](project/members/index.md).
The following table depicts the various user permission levels in a project.
@ -193,7 +192,7 @@ Project features like wiki and issues can be hidden from users depending on
which visibility level you select on project settings.
- Disabled: disabled for everyone
- Only team members: only team members will see even if your project is public or internal
- Only team members: only team members can see even if your project is public or internal
- Everyone with access: everyone can see depending on your project visibility level
- Everyone: enabled for everyone (only available for GitLab Pages)
@ -310,10 +309,10 @@ External users:
logged out).
Access can be granted by adding the user as member to the project or group.
Like usual users, they will receive a role in the project or group with all
Like usual users, they receive a role in the project or group with all
the abilities that are mentioned in the [permissions table above](#project-members-permissions).
For example, if an external user is added as Guest, and your project is
private, they will not have access to the code; you would need to grant the external
private, they do not have access to the code; you need to grant the external
user access at the Reporter level or above if you want them to have access to the code. You should
always take into account the
[project's visibility and permissions settings](project/settings/index.md#sharing-and-permissions)
@ -326,7 +325,7 @@ An administrator can flag a user as external by either of the following methods:
- Either [through the API](../api/users.md#user-modification).
- Or by navigating to the **Admin Area > Overview > Users** to create a new user
or edit an existing one. There, you will find the option to flag the user as
or edit an existing one. There, you can find the option to flag the user as
external.
### Setting new users to external
@ -334,14 +333,14 @@ An administrator can flag a user as external by either of the following methods:
By default, new users are not set as external users. This behavior can be changed
by an administrator on the **Admin Area > Settings > General** page, under **Account and limit**.
If you change the default behavior of creating new users as external, you will
If you change the default behavior of creating new users as external, you
have the option to narrow it down by defining a set of internal users.
The **Internal users** field allows specifying an email address regex pattern to
identify default internal users. New users whose email address matches the regex
pattern will be set to internal by default rather than an external collaborator.
pattern are set to internal by default rather than an external collaborator.
The regex pattern format is Ruby, but it needs to be convertible to JavaScript,
and the ignore case flag will be set (`/regex pattern/i`). Here are some examples:
and the ignore case flag is set (`/regex pattern/i`). Here are some examples:
- Use `\.internal@domain\.com$` to mark email addresses ending with
`.internal@domain.com` as internal.
@ -356,21 +355,21 @@ Be aware that this regex could lead to a
When a user is given Guest permissions on a project, group, or both, and holds no
higher permission level on any other project or group on the GitLab instance,
the user is considered a guest user by GitLab and will not consume a license seat.
the user is considered a guest user by GitLab and does not consume a license seat.
There is no other specific "guest" designation for newly created users.
If the user is assigned a higher role on any projects or groups, the user will
take a license seat. If a user creates a project, the user becomes a Maintainer
If the user is assigned a higher role on any projects or groups, the user
takes a license seat. If a user creates a project, the user becomes a Maintainer
on the project, resulting in the use of a license seat. Also, note that if your
project is internal or private, Guest users will have all the abilities that are
project is internal or private, Guest users have all the abilities that are
mentioned in the [permissions table above](#project-members-permissions) (they
will not be able to browse the project's repository for example).
are unable to browse the project's repository, for example).
TIP: **Tip:**
To prevent a guest user from creating projects, as an admin, you can edit the
user's profile to mark the user as [external](#external-users-core-only).
Beware though that even if a user is external, if they already have Reporter or
higher permissions in any project or group, they will **not** be counted as a
higher permissions in any project or group, they are **not** counted as a
free guest user.
## Auditor users **(PREMIUM ONLY)**

18
doc/user/profile/personal_access_tokens.md
View File

@ -17,7 +17,7 @@ You can also use personal access tokens with Git to authenticate over HTTP or SS
Personal access tokens expire on the date you define, at midnight UTC.
- GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that will expire in under seven days. The owners of these tokens are notified by email.
- GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that expire in under seven days. The owners of these tokens are notified by email.
- In GitLab Ultimate, administrators may [limit the lifetime of personal access tokens](../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens-ultimate-only).
- In GitLab Ultimate, administrators may [toggle enforcement of personal access token expiry](../admin_area/settings/account_and_limit_settings.md#optional-enforcement-of-personal-access-token-expiry-ultimate-only).
@ -36,8 +36,8 @@ profile.
1. Choose a name and optional expiry date for the token.
1. Choose the [desired scopes](#limiting-scopes-of-a-personal-access-token).
1. Click the **Create personal access token** button.
1. Save the personal access token somewhere safe. Once you leave or refresh
the page, you won't be able to access it again.
1. Save the personal access token somewhere safe. If you navigate away or refresh
your page, and you did not save the token, you must create a new one.
### Revoking a personal access token
@ -46,7 +46,7 @@ respective **Revoke** button under the **Active Personal Access Token** area.
### Token activity
You can see when a token was last used from the **Personal Access Tokens** page. Updates to the token usage is fixed at once per 24 hours. Requests to [API resources](../../api/api_resources.md) and the [GraphQL API](../../api/graphql/index.md) will update a token's usage.
You can see when a token was last used from the **Personal Access Tokens** page. Updates to the token usage is fixed at once per 24 hours. Requests to [API resources](../../api/api_resources.md) and the [GraphQL API](../../api/graphql/index.md) update a token's usage.
## Limiting scopes of a personal access token
@ -60,14 +60,14 @@ the following table.
| `api` | [GitLab 8.15](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5951) | Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry. |
| `read_api` | [GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28944) | Grants read access to the API, including all groups and projects, the container registry, and the package registry. |
| `read_registry` | [GitLab 9.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11845) | Allows to read (pull) [container registry](../packages/container_registry/index.md) images if a project is private and authorization is required. |
| `sudo` | [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14838) | Allows performing API actions as any user in the system (if the authenticated user is an admin). |
| `sudo` | [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14838) | Allows performing API actions as any user in the system (if the authenticated user is an administrator). |
| `read_repository` | [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17894) | Allows read-only access (pull) to the repository through `git clone`. |
| `write_repository` | [GitLab 11.11](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26021) | Allows read-write access (pull, push) to the repository through `git clone`. Required for accessing Git repositories over HTTP when 2FA is enabled. |
## Programmatically creating a personal access token
You can programmatically create a predetermined personal access token for use in
automation or tests. You will need sufficient access to run a
automation or tests. You need sufficient access to run a
[Rails console session](../../administration/troubleshooting/debug.md#starting-a-rails-console-session)
for your GitLab instance.
@ -89,15 +89,15 @@ sudo gitlab-rails runner "token = User.find_by_username('automation-bot').person
```
NOTE: **Note:**
The token string must be 20 characters in length, or it will not be
recognized as a personal access token.
The token string must be 20 characters in length to be
recognized as a valid personal access token.
The list of valid scopes and what they do can be found
[in the source code](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/auth.rb).
## Programmatically revoking a personal access token
You can programmatically revoke a personal access token. You will need
You can programmatically revoke a personal access token. You need
sufficient access to run a [Rails console session](../../administration/troubleshooting/debug.md#starting-a-rails-console-session)
for your GitLab instance.

14
doc/user/project/badges.md
View File

@ -36,6 +36,20 @@ clicking on the trash icon.
Badges associated with a group can only be edited or deleted on the
[group level](#group-badges).
### Example project badge: Pipeline Status
A common project badge presents the GitLab CI pipeline status.
To add this badge to a project:
1. Navigate to your project's **Settings > General > Badges**.
1. Under **Name**, enter _Pipeline Status_.
1. Under **Link**, enter the following URL:
`https://gitlab.com/%{project_path}/-/commits/%{default_branch}`
1. Under **Badge image URL**, enter the following URL:
`https://gitlab.com/%{project_path}/badges/%{default_branch}/pipeline.svg`
1. Submit the badge by clicking the **Add badge** button.
## Group badges
Badges can be added to a group and will then be visible on every project's

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

@ -75,7 +75,7 @@ Select **Enable integration**.
Select a **Trigger** action. This determines whether a mention of a Jira issue in GitLab commits, merge requests, or both, should link the Jira issue back to that source commit/MR and transition the Jira issue, if indicated.
To include a comment on the Jira issue when the above referene is made in GitLab, check **Enable comments**.
To include a comment on the Jira issue when the above reference is made in GitLab, check **Enable comments**.
Enter the further details on the page as described in the following table.

36
doc/user/project/merge_requests/creating_merge_requests.md
View File

@ -21,7 +21,7 @@ or through the [GitLab UI](#new-merge-request-from-a-new-branch-created-through-
This document describes the several ways to create a merge request.
When you start a new merge request, regardless of the method,
you'll be taken to the [**New Merge Request** page](#new-merge-request-page)
you are taken to the [**New Merge Request** page](#new-merge-request-page)
to fill it with information about the merge request.
If you push a new branch to GitLab, also regardless of the method,
@ -32,8 +32,8 @@ button and start a merge request from there.
On the **New Merge Request** page, start by filling in the title
and description for the merge request. If there are already
commits on the branch, the title will be prefilled with the first
line of the first commit message, and the description will be
commits on the branch, the title is prefilled with the first
line of the first commit message, and the description is
prefilled with any additional lines in the commit message.
The title is the only field that is mandatory in all cases.
@ -64,18 +64,18 @@ You can also see the **Create merge request** button in the top-right of the:
- **Repository > Files** page.
- **Merge Requests** page.
In this case, GitLab will use the most recent branch you pushed
In this case, GitLab uses the most recent branch you pushed
changes to as the source branch, and the default branch in the current
project as the target.
## New merge request by adding, editing, and uploading a file
When you choose to edit, add, or upload a file through the GitLab UI,
at the end of the file you'll see the option to add the **Commit message**,
at the end of the file you see the option to add the **Commit message**,
to select the **Target branch** of that commit, and the checkbox to
**Start new a merge request with these changes**.
Similarly, if you change files through the Web IDE, when you navigate to **Commit** on the left-hand sidebar, you'll see these same options.
Similarly, if you change files through the Web IDE, when you navigate to **Commit** on the left-hand sidebar, you see these same options.
Once you have added, edited, or uploaded the file:
@ -84,23 +84,23 @@ Once you have added, edited, or uploaded the file:
1. Keep the checkbox checked to start a new merge request straightaway, or, uncheck it to add more changes to that branch before starting the merge request.
1. Click **Commit changes**.
If you chose to start a merge request, you'll be taken to the
If you chose to start a merge request, you are taken to the
[**New Merge Request** page](#new-merge-request-page), from
which you can fill it in with information and submit the merge request.
The merge request will target the default branch of the repository.
The merge request targets the default branch of the repository.
If you want to change it, you can do it later by editing the merge request.
## New merge request from a new branch created through the UI
To quickly start working on files through the GitLab UI,
navigate to your project's **Repository > Branches** and click
**New branch**. A new branch will be created and you can start
**New branch**. A new branch is created and you can start
editing files.
Once committed and pushed, you can click on the [**Create Merge Request**](#create-merge-request-button)
button to open the [**New Merge Request** page](#new-merge-request-page).
A new merge request will be started using the current branch as the source,
A new merge request is started using the current branch as the source,
and the default branch in the current project as the target.
## New merge request from your local environment
@ -126,7 +126,7 @@ Once you're done, [push your branch to GitLab](../../../gitlab-basics/start-usin
git push origin my-new-branch
```
In the output, GitLab will prompt you with a direct link for creating
In the output, GitLab prompts you with a direct link for creating
a merge request:
```shell
@ -136,7 +136,7 @@ remote: https://gitlab-instance.com/my-group/my-project/merge_requests/new?mer
```
Copy that link and paste it in your browser, and the [**New Merge Request page**](#new-merge-request-page)
will be displayed.
is displayed.
There is also a number of [flags you can add to commands when pushing through the command line](../push_options.md) to reduce the need for editing merge requests manually through the UI.
@ -186,10 +186,10 @@ available in GitLab.com.
You can create a new merge request by sending an email to a user-specific email
address. The address can be obtained on the merge requests page by clicking on
a **Email a new merge request to this project** button. The subject will be
a **Email a new merge request to this project** button. The subject is
used as the source branch name for the new merge request and the target branch
will be the default branch for the project. The message body (if not empty)
will be used as the merge request description. You need
is the default branch for the project. The message body (if not empty)
is used as the merge request description. You need
["Reply by email"](../../../administration/reply_by_email.md) enabled to use
this feature. If it's not enabled to your instance, you may ask your GitLab
administrator to do so.
@ -210,16 +210,16 @@ or contacts to continue working._
You can add commits to the merge request being created by adding
patches as attachments to the email. All attachments with a filename
ending in `.patch` will be considered patches and they will be processed
ending in `.patch` are considered patches and they are processed
ordered by name.
The combined size of the patches can be 2MB.
If the source branch from the subject does not exist, it will be
If the source branch from the subject does not exist, it is
created from the repository's HEAD or the specified target branch to
apply the patches. The target branch can be specified using the
[`/target_branch` quick action](../quick_actions.md). If the source
branch already exists, the patches will be applied on top of it.
branch already exists, the patches are applied on top of it.
## Reviewing and managing Merge Requests

4
doc/user/project/static_site_editor/index.md
View File

@ -61,7 +61,7 @@ click of a button:
When an editor submits their changes, in the background, GitLab automatically
creates a new branch, commits their changes, and opens a merge request. The
editor will land directly on the merge request, and then they can assign it to
editor lands directly on the merge request, and then they can assign it to
a colleague for review.
## Getting started
@ -76,7 +76,7 @@ easily edit your content.
template. You can either [fork it](../repository/forking_workflow.md#creating-a-fork)
or [create a new project from a template](../../../gitlab-basics/create-project.md#built-in-templates).
1. Edit the `data/config.yml` file adding your project's path.
1. Editing the file will trigger a CI/CD pipeline to deploy your project with GitLab Pages.
1. Editing the file triggers a CI/CD pipeline to deploy your project with GitLab Pages.
1. When the pipeline finishes, from your project's left-side menu, go to **Settings > Pages** to find the URL of your new website.
1. Visit your website and look at the bottom-left corner of the screen to see the new **Edit this page** button.

7
lib/product_analytics/event_params.rb
View File

@ -40,7 +40,12 @@ module ProductAnalytics
domain_userid: params['duid'],
user_fingerprint: params['fp'],
page_referrer: params['refr'],
page_url: params['url']
page_url: params['url'],
se_category: params['se_ca'],
se_action: params['se_ac'],
se_label: params['se_la'],
se_property: params['se_pr'],
se_value: params['se_va']
}
end

7
spec/fixtures/product_analytics/event.json vendored
View File

@ -12,5 +12,10 @@
"lang":"en-US",
"cookie":"1",
"tz":"America/Los_Angeles",
"cs":"UTF-8"
"cs":"UTF-8",
"se_ca": "category",
"se_ac": "action",
"se_la": "label",
"se_pr": "property",
"se_va": 12.34
}

7
spec/lib/product_analytics/event_params_spec.rb
View File

@ -23,7 +23,12 @@ RSpec.describe ProductAnalytics::EventParams do
br_lang: 'en-US',
br_cookies: true,
os_timezone: 'America/Los_Angeles',
doc_charset: 'UTF-8'
doc_charset: 'UTF-8',
se_category: 'category',
se_action: 'action',
se_label: 'label',
se_property: 'property',
se_value: 12.34
}
expect(subject).to include(expected_params)

20
spec/requests/product_analytics/collector_app_spec.rb
View File

@ -5,6 +5,7 @@ require 'spec_helper'
RSpec.describe 'ProductAnalytics::CollectorApp' do
let_it_be(:project) { create(:project) }
let(:params) { {} }
let(:raw_event) { Gitlab::Json.parse(fixture_file('product_analytics/event.json')) }
subject { get '/-/collector/i', params: params }
@ -17,24 +18,7 @@ RSpec.describe 'ProductAnalytics::CollectorApp' do
end
context 'correct event params' do
let(:params) do
{
aid: project.id,
p: 'web',
tna: 'sp',
tv: 'js-2.14.0',
eid: SecureRandom.uuid,
duid: SecureRandom.uuid,
sid: SecureRandom.uuid,
vid: 4,
url: 'http://example.com/products/1',
refr: 'http://example.com/products/1',
lang: 'en-US',
cookie: true,
tz: 'America/Los_Angeles',
cs: 'UTF-8'
}
end
let(:params) { raw_event.merge(aid: project.id) }
it 'repond with 200' do
expect { subject }.to change { ProductAnalyticsEvent.count }.by(1)