From 54763b367cd828086a6f4a9956484ce0229ae1b7 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Mon, 10 Aug 2020 00:10:20 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- doc/README.md | 6 +- doc/ci/docker/using_docker_build.md | 40 ++++++------ doc/ci/pipelines/job_artifacts.md | 64 ++++++++----------- doc/ci/runners/README.md | 9 ++- doc/install/installation.md | 36 +++++------ doc/user/packages/conan_repository/index.md | 44 ++++++------- doc/user/packages/container_registry/index.md | 63 +++++++++--------- doc/user/packages/pypi_repository/index.md | 16 ++--- doc/user/permissions.md | 33 +++++----- doc/user/profile/personal_access_tokens.md | 18 +++--- doc/user/project/badges.md | 14 ++++ doc/user/project/integrations/jira.md | 2 +- .../merge_requests/creating_merge_requests.md | 36 +++++------ doc/user/project/static_site_editor/index.md | 4 +- lib/product_analytics/event_params.rb | 7 +- spec/fixtures/product_analytics/event.json | 7 +- .../product_analytics/event_params_spec.rb | 7 +- .../product_analytics/collector_app_spec.rb | 20 +----- 18 files changed, 215 insertions(+), 211 deletions(-) diff --git a/doc/README.md b/doc/README.md index 43a155a730b..5e5d76374a2 100644 --- a/doc/README.md +++ b/doc/README.md @@ -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. |
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 4bed6d9e323..88d6dc3aae4 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -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: . + certificates inside of that directory. For more information on how + Docker with TLS works, check . - 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 diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md index 3d034da58a6..be6886fe6b2 100644 --- a/doc/ci/pipelines/job_artifacts.md +++ b/doc/ci/pipelines/job_artifacts.md @@ -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. diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index 967011f8ef0..6d248156004 100644 --- a/doc/ci/runners/README.md +++ b/doc/ci/runners/README.md @@ -7,7 +7,7 @@ type: reference # Configuring GitLab Runners - + 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. diff --git a/doc/install/installation.md b/doc/install/installation.md index b2da1e0eac9..6c76dd0538a 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -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. diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md index c1477648887..e8014ad2b84 100644 --- a/doc/user/packages/conan_repository/index.md +++ b/doc/user/packages/conan_repository/index.md @@ -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 -r gitlab -p @@ -133,10 +133,10 @@ conan user -r gitlab -p CONAN_PASSWORD= --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 diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md index 6f865604a08..673768da065 100644 --- a/doc/user/packages/container_registry/index.md +++ b/doc/user/packages/container_registry/index.md @@ -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 /// @@ -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). diff --git a/doc/user/packages/pypi_repository/index.md b/doc/user/packages/pypi_repository/index.md index 5439675dd83..63e6cd7b5b4 100644 --- a/doc/user/packages/pypi_repository/index.md +++ b/doc/user/packages/pypi_repository/index.md @@ -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 = ### 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: diff --git a/doc/user/permissions.md b/doc/user/permissions.md index 93d115b4644..9cd3d0ff9c6 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -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)** diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md index 59ca124f566..572cfe19322 100644 --- a/doc/user/profile/personal_access_tokens.md +++ b/doc/user/profile/personal_access_tokens.md @@ -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. diff --git a/doc/user/project/badges.md b/doc/user/project/badges.md index 6b60ea444e3..ed6e2460554 100644 --- a/doc/user/project/badges.md +++ b/doc/user/project/badges.md @@ -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 diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md index 3a950a9f1c6..79c497489db 100644 --- a/doc/user/project/integrations/jira.md +++ b/doc/user/project/integrations/jira.md @@ -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. diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md index b507cc45c99..0495c864335 100644 --- a/doc/user/project/merge_requests/creating_merge_requests.md +++ b/doc/user/project/merge_requests/creating_merge_requests.md @@ -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 diff --git a/doc/user/project/static_site_editor/index.md b/doc/user/project/static_site_editor/index.md index 0dbea478e5f..1ac0026a7f2 100644 --- a/doc/user/project/static_site_editor/index.md +++ b/doc/user/project/static_site_editor/index.md @@ -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. diff --git a/lib/product_analytics/event_params.rb b/lib/product_analytics/event_params.rb index d938fe1f594..07e0bc8b43a 100644 --- a/lib/product_analytics/event_params.rb +++ b/lib/product_analytics/event_params.rb @@ -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 diff --git a/spec/fixtures/product_analytics/event.json b/spec/fixtures/product_analytics/event.json index 3100b068a0c..1a4db860be2 100644 --- a/spec/fixtures/product_analytics/event.json +++ b/spec/fixtures/product_analytics/event.json @@ -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 } diff --git a/spec/lib/product_analytics/event_params_spec.rb b/spec/lib/product_analytics/event_params_spec.rb index d6c098599d6..e560fd10dfd 100644 --- a/spec/lib/product_analytics/event_params_spec.rb +++ b/spec/lib/product_analytics/event_params_spec.rb @@ -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) diff --git a/spec/requests/product_analytics/collector_app_spec.rb b/spec/requests/product_analytics/collector_app_spec.rb index 0491c2564f0..b87610841e7 100644 --- a/spec/requests/product_analytics/collector_app_spec.rb +++ b/spec/requests/product_analytics/collector_app_spec.rb @@ -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)