diff options
Diffstat (limited to 'doc')
42 files changed, 212 insertions, 265 deletions
diff --git a/doc/administration/monitoring/prometheus/gitlab_exporter.md b/doc/administration/monitoring/prometheus/gitlab_exporter.md index cfd9f55acc3..f6178799e0a 100644 --- a/doc/administration/monitoring/prometheus/gitlab_exporter.md +++ b/doc/administration/monitoring/prometheus/gitlab_exporter.md @@ -1,12 +1,16 @@ # GitLab exporter ->**Note:** -Available since [Omnibus GitLab 8.17][1132]. For installations from source -you'll have to install and configure it yourself. +>- Available since [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132). +>- Renamed from `GitLab monitor exporter` to `GitLab exporter` in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/merge_requests/16511). -The [GitLab exporter] allows you to measure various GitLab metrics, pulled from Redis and the database. +The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) allows you to +measure various GitLab metrics, pulled from Redis and the database, in Omnibus GitLab +instances. -To enable the GitLab exporter: +NOTE: **Note:** +For installations from source you'll have to install and configure it yourself. + +To enable the GitLab exporter in an Omnibus GitLab instance: 1. [Enable Prometheus](index.md#configuring-prometheus) 1. Edit `/etc/gitlab/gitlab.rb` @@ -16,15 +20,10 @@ To enable the GitLab exporter: gitlab_exporter['enable'] = true ``` -1. Save the file and [reconfigure GitLab][reconfigure] for the changes to - take effect +1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) + for the changes to take effect Prometheus will now automatically begin collecting performance data from the GitLab exporter exposed under `localhost:9168`. [← Back to the main Prometheus page](index.md) - -[1132]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132 -[GitLab exporter]: https://gitlab.com/gitlab-org/gitlab-exporter -[prometheus]: https://prometheus.io -[reconfigure]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure diff --git a/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md b/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md new file mode 100644 index 00000000000..ae3a3d739b5 --- /dev/null +++ b/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md @@ -0,0 +1,5 @@ +--- +redirect_to: 'gitlab_exporter.md' +--- + +This document was moved to [another location](gitlab_exporter.md). diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png Binary files differdeleted file mode 100644 index 6d4b66824e1..00000000000 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png +++ /dev/null diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png Binary files differnew file mode 100644 index 00000000000..6f0752bb940 --- /dev/null +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md index ced6efc415b..3a0848fcd08 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md +++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md @@ -20,7 +20,7 @@ GitLab can run pipelines for merge requests on this merged result. That is, where the source and target branches are combined into a new ref and a pipeline for this ref validates the result prior to merging. - + There are some cases where creating a combined ref is not possible or not wanted. For example, a source branch that has conflicts with the target branch diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index 0fc15ac87e3..52f712abfae 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -60,12 +60,12 @@ future GitLab releases.** | `CI_MERGE_REQUEST_PROJECT_URL` | 11.6 | all | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_REF_PATH` | 11.6 | all | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | 11.6 | all | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | -| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | +| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** | | `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | 11.6 | all | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6 | all | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | 11.6 | all | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | -| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | +| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** | | `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_ASSIGNEES` | 11.9 | all | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | | `CI_MERGE_REQUEST_MILESTONE` | 11.9 | all | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index a9f30a5ddd4..1a7c358eb91 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -3309,13 +3309,8 @@ all updated Merge Requests will have a pipeline created when using If your commit message contains `[ci skip]` or `[skip ci]`, using any capitalization, the commit will be created but the pipeline will be skipped. -Alternatively, one can pass the `ci.skip` [Git push option][push-option] if -using Git 2.10 or newer: - -```sh -git push --push-option=ci.skip # using git 2.10+ -git push -o ci.skip # using git 2.18+ -``` +Alternatively, one can pass the `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd) +if using Git 2.10 or newer. <!-- ## Troubleshooting diff --git a/doc/development/architecture.md b/doc/development/architecture.md index fb5d94d5e88..ee2a426db97 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -12,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th ## Components -A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs. +A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs. We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/). @@ -20,7 +20,7 @@ The GitLab web app uses PostgreSQL for persistent database information (e.g. use When serving repositories over HTTP/HTTPS GitLab utilizes the GitLab API to resolve authorization and access as well as serving Git objects. -The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access. +The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with Redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access. Gitaly executes Git operations from GitLab Shell and the GitLab web app, and provides an API to the GitLab web app to get attributes from Git (e.g. title, branches, tags, other meta data), and to get blobs (e.g. diffs, commits, files). @@ -224,7 +224,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag - Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk] - Layer: Core Service (Processor) -#### Gitlab Exporter +#### GitLab Exporter - [Project page](https://gitlab.com/gitlab-org/gitlab-exporter) - Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts] @@ -258,7 +258,7 @@ GitLab CI is the open-source continuous integration service included with GitLab - Configuration: [Omnibus][shell-omnibus], [Charts][shell-charts], [Source][shell-source], [GDK][gitlab-yml] - Layer: Core Service (Processor) -[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle ssh-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh. +[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle SSH-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh. #### GitLab Workhorse @@ -317,7 +317,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp - Layer: Core Service (Processor) - Process: `nginx` -Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver. +NGINX has an Ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver. #### Node Exporter @@ -344,7 +344,7 @@ Lightweight connection pooler for PostgreSQL. Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics. -#### Postgresql +#### PostgreSQL - [Project page](https://github.com/postgres/postgres/blob/master/README) - Configuration: [Omnibus][postgres-omnibus], [Charts][postgres-charts], [Source][postgres-source] @@ -400,7 +400,7 @@ Redis is packaged to provide a place to store: - Layer: Core Service (Processor) The registry is what users use to store their own Docker images. The bundled -registry uses nginx as a load balancer and GitLab as an authentication manager. +registry uses NGINX as a load balancer and GitLab as an authentication manager. Whenever a client requests to pull or push an image from the registry, it will return a `401` response along with a header detailing where to get an authentication token, in this case the GitLab instance. The client will then @@ -424,7 +424,7 @@ Sentry fundamentally is a service that helps you monitor and fix crashes in real - Layer: Core Service (Processor) - Process: `sidekiq` -Sidekiq is a Ruby background job processor that pulls jobs from the redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background. +Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background. #### Unicorn @@ -470,9 +470,9 @@ It's important to understand the distinction as some processes are used in both When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service: -- nginx - Acts as our first line reverse proxy. +- NGINX - Acts as our first line reverse proxy. - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn. -- unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn. +- Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn. - Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data. ### GitLab Git Request Cycle @@ -508,7 +508,7 @@ ps aux | grep '^git' ``` GitLab has several components to operate. It requires a persistent database -(PostgreSQL) and redis database, and uses Apache httpd or Nginx to proxypass +(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass Unicorn. All these components should run as different system users to GitLab (e.g., `postgres`, `redis` and `www-data`, instead of `git`). @@ -580,7 +580,7 @@ SSH: - `/var/log/auth.log` auth log (on Ubuntu). - `/var/log/secure` auth log (on RHEL). -nginx: +NGINX: - `/var/log/nginx/` contains error and access logs. diff --git a/doc/development/changelog.md b/doc/development/changelog.md index 954a4de53a0..8ded3f393ee 100644 --- a/doc/development/changelog.md +++ b/doc/development/changelog.md @@ -79,7 +79,7 @@ changes. - **Bad:** Strip out `nil`s in the Array of Commit objects returned from `find_commits_by_message_with_elastic` -- **Good:** Fix 500 errors caused by elasticsearch results referencing +- **Good:** Fix 500 errors caused by Elasticsearch results referencing garbage-collected commits The first example focuses on _how_ we fixed something, not on _what_ it fixes. diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md index 6c9fa983c96..9947f9c16c0 100644 --- a/doc/development/database_debugging.md +++ b/doc/development/database_debugging.md @@ -3,7 +3,7 @@ This section is to help give some copy-pasta you can use as a reference when you run into some head-banging database problems. -An easy first step is to search for your error in Slack or google "GitLab (my error)". +An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google. --- diff --git a/doc/development/documentation/improvement-workflow.md b/doc/development/documentation/improvement-workflow.md index c8e9368fb74..3bbb45debfb 100644 --- a/doc/development/documentation/improvement-workflow.md +++ b/doc/development/documentation/improvement-workflow.md @@ -20,7 +20,7 @@ to accomplish their work with GitLab. ## How to update the docs -1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to +1. Click "Edit this Page" at the bottom of any page on <https://docs.gitlab.com>, or navigate to one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page. Work in a fork if you do not have developer access to the GitLab project. 1. Follow the described standards and processes listed on that Guidelines page, diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md index 4ad24d08d17..a5b47b3a5c0 100644 --- a/doc/development/documentation/index.md +++ b/doc/development/documentation/index.md @@ -8,19 +8,18 @@ GitLab's documentation is [intended as the single source of truth (SSOT)](https: In addition to this page, the following resources can help you craft and contribute documentation: -- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, and more. +- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, Markdown standards to follow, and more. - [Structure and template](structure.md) - Learn the typical parts of a doc page and how to write each one. - [Workflows](workflow.md) - A landing page for our key workflows: - [Documentation process for feature changes](feature-change-workflow.md) - Adding required documentation when developing a GitLab feature. - [Documentation improvement workflow](improvement-workflow.md) - New content not associated with a new feature. -- [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) - A reference for the markdown implementation used by GitLab's documentation site and about.gitlab.com. -- [Site architecture](site_architecture/index.md) - How docs.gitlab.com is built. +- [Markdown Guide](../../user/markdown.md) - A reference for all markdown syntax supported by GitLab. +- [Site architecture](site_architecture/index.md) - How <http://docs.gitlab.com> is built. ## Source files and rendered web locations -Documentation for GitLab, GitLab Runner, and Omnibus is published to [docs.gitlab.com](https://docs.gitlab.com). Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance. - -At `/help`, only help for your current edition and version is included. Help for other versions is available at docs.gitlab.com. +Documentation for GitLab, GitLab Runner, Omnibus GitLab and Charts are published to <https://docs.gitlab.com>. Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance. +At `/help`, only help for your current edition and version is included. Help for other versions is available at <https://docs.gitlab.com/archives/>. The source of the documentation exists within the codebase of each GitLab application in the following repository locations: @@ -29,6 +28,7 @@ The source of the documentation exists within the codebase of each GitLab applic | [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) | | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) | | [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) | +| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) | Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`. @@ -55,8 +55,8 @@ See the [Structure](styleguide.md#structure) section of the [Documentation Style Changing a document's location requires specific steps to ensure that users can seamlessly access the new doc page, whether they are accessing content -on a GitLab instance domain at `/help` or at docs.gitlab.com. Be sure to ping a -GitLab technical writer if you have any questions during the process (such as +on a GitLab instance domain at `/help` or at <https://docs.gitlab.com>. Be sure to assign a +technical writer if you have any questions during the process (such as whether the move is necessary), and ensure that a technical writer reviews this change prior to merging. @@ -132,7 +132,7 @@ land on the doc via `/help`. If the documentation page being relocated already has Disqus comments, we need to preserve the Disqus thread. -Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier +Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier is configured to be the page URL. Therefore, when we change the document location, we need to preserve the old URL as the same Disqus identifier. @@ -181,9 +181,9 @@ Every GitLab instance includes the documentation, which is available at `/help` (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>. There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this -practice and instead link out from the GitLab application to docs.gitlab.com URLs. +practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs. -The documentation available online on docs.gitlab.com is continuously +The documentation available online on <https://docs.gitlab.com> is continuously deployed every hour from the `master` branch of GitLab, Omnibus, and Runner. Therefore, once a merge request gets merged, it will be available online on the same day. However, they will be shipped (and available on `/help`) within the milestone assigned @@ -195,7 +195,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if the MR does not have a "pick into 11.3" label, the milestone has to be changed to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22, with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab -11.4 onwards, but available on docs.gitlab.com on the same day it was merged. +11.4 onwards, but available on <https://docs.gitlab.com/archives/> on the same day it was merged. ### Linking to `/help` @@ -271,7 +271,7 @@ For example, [GitLab.com's `/help`](https://gitlab.com/help). ## Docs site architecture See the [Docs site architecture](site_architecture/index.md) page to learn -how we build and deploy the site at [docs.gitlab.com](https://docs.gitlab.com) and +how we build and deploy the site at <https://docs.gitlab.com> and to review all the assets and libraries in use. ### Global navigation @@ -301,7 +301,7 @@ You will need to push a branch to those repositories, it doesn't work for forks. The `review-docs-deploy*` job will: -1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs) +1. Create a new branch in the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`, where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for CE, etc. diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md index 2fd3cb06a37..c3bbf86492f 100644 --- a/doc/development/documentation/styleguide.md +++ b/doc/development/documentation/styleguide.md @@ -564,7 +564,7 @@ Inside the document: ### Remove image shadow -All images displayed on docs.gitlab.com have a box shadow by default. +All images displayed on the [GitLab Docs site](https://docs.gitlab.com) have a box shadow by default. To remove the box shadow, use the image class `.image-noshadow` applied directly to an HTML `img` tag: @@ -598,7 +598,7 @@ You can link any up-to-date video that is useful to the GitLab user. > [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1. -GitLab docs (docs.gitlab.com) support embedded videos. +The [GitLab docs site](https://docs.gitlab.com) supports embedded videos. You can only embed videos from [GitLab's official YouTube account](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg). @@ -634,7 +634,7 @@ leave a blank line here leave a blank line here ``` -This is how it renders on docs.gitlab.com: +This is how it renders on the GitLab Docs site: <div class="video-fallback"> See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>. @@ -693,6 +693,10 @@ use the following markup for highlighting. _Note that the alert boxes only work for one paragraph only. Multiple paragraphs, lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._ +Alert boxes only render properly on the GitLab Docs site (<http://docs.gitlab.com>). +Within GitLab itself, they will appear as plain markdown text (like the examples +above the rendered versions, below). + ### Note Notes catch the eye of most readers, and therefore should be used very sparingly. @@ -717,7 +721,7 @@ NOTE: **Note:** This is something to note. ``` -How it renders in docs.gitlab.com: +How it renders on the GitLab Docs site: NOTE: **Note:** This is something to note. @@ -729,7 +733,7 @@ TIP: **Tip:** This is a tip. ``` -How it renders in docs.gitlab.com: +How it renders on the GitLab Docs site: TIP: **Tip:** This is a tip. @@ -741,7 +745,7 @@ CAUTION: **Caution:** This is something to be cautious about. ``` -How it renders in docs.gitlab.com: +How it renders on the GitLab Docs site: CAUTION: **Caution:** This is something to be cautious about. @@ -753,7 +757,7 @@ DANGER: **Danger:** This is a breaking change, a bug, or something very important to note. ``` -How it renders in docs.gitlab.com: +How it renders on the GitLab Docs site: DANGER: **Danger:** This is a breaking change, a bug, or something very important to note. @@ -766,7 +770,7 @@ For highlighting a text within a blue blockquote, use this format: > This is a blockquote. ``` -which renders in docs.gitlab.com to: +which renders on the [GitLab Docs site](https://docs.gitlab.com) as: > This is a blockquote. @@ -1154,7 +1158,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title= ``` The above example is run by and administrator and will add an SSH public key -titled ssh-key to user's account which has an id of 25. +titled `ssh-key` to user's account which has an id of 25. #### Escape special characters diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index af350f8911a..a63712dac20 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -1,8 +1,9 @@ # Elasticsearch knowledge **(STARTER ONLY)** -This area is to maintain a compendium of useful information when working with elasticsearch. +This area is to maintain a compendium of useful information when working with Elasticsearch. -Information on how to enable Elasticsearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch +Information on how to enable Elasticsearch and perform the initial indexing is in +the [Elasticsearch integration documentation](../integration/elasticsearch.md#enabling-elasticsearch) ## Deep Dive @@ -61,7 +62,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb). -All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs). +All indexing after the initial one is done via `ElasticIndexerWorker` (Sidekiq jobs). Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them! diff --git a/doc/development/event_tracking/frontend.md b/doc/development/event_tracking/frontend.md index cdc2e94bf9e..a3a7b4ca152 100644 --- a/doc/development/event_tracking/frontend.md +++ b/doc/development/event_tracking/frontend.md @@ -1,6 +1,6 @@ # Frontend tracking guide -GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). +GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). | field | type | default value | description | |:-----------|:-------|:---------------------------|:------------| @@ -26,7 +26,7 @@ Below is an example of `data-track-*` attributes assigned to a button: /> ``` -Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript). +Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript). Below is a list of supported `data-track-*` attributes: @@ -99,7 +99,7 @@ And if needed within the template, you can use the `track` method directly as we </template> ``` -## Tracking in raw Javascript +## Tracking in raw JavaScript Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually. diff --git a/doc/development/fe_guide/components.md b/doc/development/fe_guide/components.md index f8765f9e202..1c5ddd5e2a5 100644 --- a/doc/development/fe_guide/components.md +++ b/doc/development/fe_guide/components.md @@ -8,7 +8,7 @@ See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns). -### How to style a bootstrap dropdown +### How to style a Bootstrap dropdown 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns] 1. Add a specific class to the top level `.dropdown` element diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md index 21e0c869f13..3724bf60757 100644 --- a/doc/development/fe_guide/development_process.md +++ b/doc/development/fe_guide/development_process.md @@ -80,7 +80,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/ 1. Before writing code, ensure your vision of the architecture is aligned with GitLab's architecture. -1. Add a diagram to the issue and ask a frontend maintainer in the slack channel `#frontend_maintainers` about it. +1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.  diff --git a/doc/development/fe_guide/icons.md b/doc/development/fe_guide/icons.md index 2b6bb0bb878..d81a520c5f3 100644 --- a/doc/development/fe_guide/icons.md +++ b/doc/development/fe_guide/icons.md @@ -1,6 +1,6 @@ # Icons and SVG Illustrations -We manage our own Icon and Illustration library in the [gitlab-svgs][gitlab-svgs] repository. +We manage our own Icon and Illustration library in the [`gitlab-svgs`][gitlab-svgs] repository. This repository is published on [npm][npm] and managed as a dependency via yarn. You can browse all available Icons and Illustrations [here][svg-preview]. To upgrade to a new version run `yarn upgrade @gitlab/svgs`. diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md index 87378535cd0..6d5021c0f08 100644 --- a/doc/development/fe_guide/performance.md +++ b/doc/development/fe_guide/performance.md @@ -65,26 +65,27 @@ within the `pages` directory correspond to Rails controllers and actions. These auto-generated bundles will be automatically included on the corresponding pages. -For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues), +For example, if you were to visit <https://gitlab.com/gitlab-org/gitlab/issues>, you would be accessing the `app/controllers/projects/issues_controller.rb` controller with the `index` action. If a corresponding file exists at `pages/projects/issues/index/index.js`, it will be compiled into a webpack bundle and included on the page. -> **Note:** Previously we had encouraged the use of -> `content_for :page_specific_javascripts` within haml files, along with -> manually generated webpack bundles. However under this new system you should -> not ever need to manually add an entry point to the `webpack.config.js` file. -> -> **Tip:** -> If you are unsure what controller and action corresponds to a given page, you -> can find this out by inspecting `document.body.dataset.page` within your -> browser's developer console while on any page within gitlab. +NOTE: **Note:** +Previously we had encouraged the use of +`content_for :page_specific_javascripts` within haml files, along with +manually generated webpack bundles. However under this new system you should +not ever need to manually add an entry point to the `webpack.config.js` file. + +TIP: **Tip:** +If you are unsure what controller and action corresponds to a given page, you +can find this out by inspecting `document.body.dataset.page` within your +browser's developer console while on any page within GitLab. #### Important Considerations - **Keep Entry Points Lite:** - Page-specific javascript entry points should be as lite as possible. These + Page-specific JavaScript entry points should be as lite as possible. These files are exempt from unit tests, and should be used primarily for instantiation and dependency injection of classes and methods that live in modules outside of the entry point script. Just import, read the DOM, diff --git a/doc/development/fe_guide/security.md b/doc/development/fe_guide/security.md index 47ac87fc895..7dba61d6b45 100644 --- a/doc/development/fe_guide/security.md +++ b/doc/development/fe_guide/security.md @@ -63,7 +63,7 @@ External fonts, CSS, and JavaScript should never be used with the exception of Google Analytics and Piwik - and only when the instance has enabled it. Assets should always be hosted and served locally from the GitLab instance. Embedded resources via `iframes` should never be used except in certain circumstances -such as with ReCaptcha, which cannot be used without an `iframe`. +such as with reCAPTCHA, which cannot be used without an `iframe`. ## Avoiding inline scripts and styles diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md index e78a2f4f453..306b19c6e5d 100644 --- a/doc/development/fe_guide/style_guide_js.md +++ b/doc/development/fe_guide/style_guide_js.md @@ -287,7 +287,7 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab/blob/master/.es #### CSS classes used for JavaScript -1. If the class is being used in Javascript it needs to be prepend with `js-` +1. If the class is being used in JavaScript it needs to be prepend with `js-` ```html // bad @@ -693,7 +693,7 @@ Useful links: $('span').tooltip('_fixTitle'); ``` -### The Javascript/Vue Accord +### The JavaScript/Vue Accord The goal of this accord is to make sure we are all on the same page. diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md index cbc98016024..c8664831736 100644 --- a/doc/development/feature_flags/controls.md +++ b/doc/development/feature_flags/controls.md @@ -3,7 +3,7 @@ In order to be able to turn on/off features behind feature flags in any of the GitLab Inc. provided environments such as staging and production, you need to have access to the chatops bot. Chatops bot is currently running on the ops instance, -which is different from GitLab.com or dev.gitlab.org. +which is different from <https://gitlab.com> or <https://dev.gitlab.org>. Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access). @@ -39,7 +39,7 @@ If you get an error "Whoops! This action is not allowed. This incident will be reported." that means your Slack account is not allowed to change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production). -### Enabling feature for staging and dev.gitlab.org +### Enabling feature for internal testing As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com> and <https://dev.gitlab.org>. diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index 792ddeed201..6194274660c 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -15,9 +15,9 @@ In May 2019, Bob Van Landuyt hosted a [Deep Dive] on GitLab's [Gitaly project] a ## Beginner's guide -Start by reading the gitaly repository's +Start by reading the Gitaly repository's [Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md). -It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites. +It describes how to setup Gitaly, the various components of Gitaly and what they do, and how to run its test suites. ## Developing new Git features @@ -41,14 +41,14 @@ disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside The process for adding new Gitaly features is: - exploration / prototyping -- design and create a new Gitaly RPC [in gitaly-proto](https://gitlab.com/gitlab-org/gitaly-proto) -- release a new version of gitaly-proto +- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto) +- release a new version of `gitaly-proto` - write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby - release a new version of Gitaly - write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC These steps often overlap. It is possible to use an unreleased version -of Gitaly and gitaly-proto during testing and development. +of Gitaly and `gitaly-proto` during testing and development. - See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol. - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly. @@ -58,7 +58,7 @@ of Gitaly and gitaly-proto during testing and development. It is possible to implement and test RPC's in Gitaly using Ruby code, in -[gitaly-ruby](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby). +[`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby). This should make it easier to contribute for developers who are less comfortable writing Go code. @@ -234,7 +234,7 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag. } ``` -1. Create prometheus metrics: +1. Create Prometheus metrics: ```go var findAllTagsRequests = prometheus.NewCounterVec( diff --git a/doc/development/i18n/index.md b/doc/development/i18n/index.md index 5e4923341af..7f59d30f8f9 100644 --- a/doc/development/i18n/index.md +++ b/doc/development/i18n/index.md @@ -29,7 +29,7 @@ See [Externalization for GitLab](externalization.md). ### Translate strings -The translation process is managed at [translate.gitlab.com](https://translate.gitlab.com) +The translation process is managed at <https://translate.gitlab.com> using [Crowdin](https://crowdin.com/). You will need to create an account before you can submit translations. Once you are signed in, select the language you wish to contribute translations to. diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md index 44d96145eb9..8b3a5d893fe 100644 --- a/doc/development/i18n/proofreader.md +++ b/doc/development/i18n/proofreader.md @@ -57,7 +57,7 @@ are very appreciative of the work done by translators and proofreaders! - Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo) - Japanese - Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz) - - Tomo Dote - [Gitlab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4) + - Tomo Dote - [GitLab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4) - Korean - Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang) - Ji Hun Oh - [GitLab](https://gitlab.com/Baw-Appie), [Crowdin](https://crowdin.com/profile/BawAppie) diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md index 1793afcd86d..c1a6fd8983c 100644 --- a/doc/development/i18n/translation.md +++ b/doc/development/i18n/translation.md @@ -8,7 +8,7 @@ The first step is to get familiar with Crowdin. ### Sign In -To contribute translations at [translate.gitlab.com](https://translate.gitlab.com) +To contribute translations at <https://translate.gitlab.com> you must create a Crowdin account. You may create a new account or use any of their supported sign in services. @@ -54,7 +54,7 @@ For example in French `OpenedNDaysAgo|Opened` would be translated to Some technical terms should be treated like proper nouns and not be translated. Technical terms that should always be in English are noted in the glossary when -using [translate.gitlab.com](https://translate.gitlab.com). +using <https://translate.gitlab.com>. This helps maintain a logical connection and consistency between tools (e.g. `git` client) and GitLab. diff --git a/doc/development/import_export.md b/doc/development/import_export.md index 71f5ce18aae..38119d9bbd0 100644 --- a/doc/development/import_export.md +++ b/doc/development/import_export.md @@ -36,7 +36,7 @@ SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000 SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900 ``` -An import status `started`, and the following sidekiq logs will signal a memory issue: +An import status `started`, and the following Sidekiq logs will signal a memory issue: ```bash WARN: Work still in progress <struct with JID> diff --git a/doc/development/interacting_components.md b/doc/development/interacting_components.md index 5e6dc8d460a..3db260d5f85 100644 --- a/doc/development/interacting_components.md +++ b/doc/development/interacting_components.md @@ -14,7 +14,7 @@ change that affects uploads should also be tested against [object storage], which is _not_ enabled by default in [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit). When working on a related feature, make sure to enable and test it -against [Minio](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md). +against [MinIO](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md). See also [File Storage in GitLab](file_storage.md). diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md index 5443bdea043..82aa02ac75d 100644 --- a/doc/development/kubernetes.md +++ b/doc/development/kubernetes.md @@ -44,12 +44,11 @@ to the relevant internal client. All calls to the Kubernetes API must be in a background process. Do not perform Kubernetes API calls within a web request as this will block -unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as +Unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as the Kubernetes cluster response times are outside of our control. The easiest way to ensure your calls happen a background process is to -delegate any such work to happen in a [sidekiq -worker](sidekiq_style_guide.md). +delegate any such work to happen in a [Sidekiq worker](sidekiq_style_guide.md). There are instances where you would like to make calls to Kubernetes and return the response and as such a background worker does not seem to be diff --git a/doc/development/new_fe_guide/development/components.md b/doc/development/new_fe_guide/development/components.md index cebdc87eab9..7cccd4b5b1b 100644 --- a/doc/development/new_fe_guide/development/components.md +++ b/doc/development/new_fe_guide/development/components.md @@ -7,7 +7,7 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo We chose D3 as our library going forward because of the following features: - [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40). -- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40). +- [Compatible with vue.js as well as vanilla JavaScript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40). D3 is very popular across many projects outside of GitLab: diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md index d41239693bf..4a85c04d8cf 100644 --- a/doc/development/new_fe_guide/development/performance.md +++ b/doc/development/new_fe_guide/development/performance.md @@ -2,9 +2,9 @@ ## Monitoring -We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated. +We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated. -These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt) +These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt) Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`. There are 3 recommended high impact metrics to review on each page: diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md index 8e268224c98..c181b31f069 100644 --- a/doc/development/sidekiq_style_guide.md +++ b/doc/development/sidekiq_style_guide.md @@ -27,7 +27,7 @@ While different workers cannot share a queue, they can share a queue namespace. Defining a queue namespace for a worker makes it possible to start a Sidekiq process that automatically handles jobs for all workers in that namespace, without needing to explicitly list all their queue names. If, for example, all -workers that are managed by sidekiq-cron use the `cronjob` queue namespace, we +workers that are managed by `sidekiq-cron` use the `cronjob` queue namespace, we can spin up a Sidekiq process specifically for these kinds of scheduled jobs. If a new worker using the `cronjob` namespace is added later on, the Sidekiq process will automatically pick up jobs for that worker too (after having been diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index b807ca906eb..32e079f915c 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -113,7 +113,7 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load) 1 example, 0 failures ``` -Note: `live_debug` only works on javascript enabled specs. +Note: `live_debug` only works on JavaScript enabled specs. #### Run `:js` spec in a visible browser @@ -158,7 +158,7 @@ really fast since: - Gems loading is skipped - Rails app boot is skipped -- gitlab-shell and Gitaly setup are skipped +- GitLab Shell and Gitaly setup are skipped - Test repositories setup are skipped `fast_spec_helper` also support autoloading classes that are located inside the @@ -347,7 +347,7 @@ them unspecified, and look up the value after the row is created. #### Redis -GitLab stores two main categories of data in Redis: cached items, and sidekiq +GitLab stores two main categories of data in Redis: cached items, and Sidekiq jobs. In most specs, the Rails cache is actually an in-memory store. This is replaced @@ -587,9 +587,9 @@ All fixtures should be placed under `spec/fixtures/`. ### Repositories -Testing some functionality, e.g., merging a merge request, requires a git +Testing some functionality, e.g., merging a merge request, requires a Git repository with a certain state to be present in the test environment. GitLab -maintains the [gitlab-test](https://gitlab.com/gitlab-org/gitlab-test) +maintains the [`gitlab-test`](https://gitlab.com/gitlab-org/gitlab-test) repository for certain common cases - you can ensure a copy of the repository is used with the `:repository` trait for project factories: diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md index 8820b54fa87..28111c18378 100644 --- a/doc/development/testing_guide/end_to_end/page_objects.md +++ b/doc/development/testing_guide/end_to_end/page_objects.md @@ -2,7 +2,7 @@ In GitLab QA we are using a known pattern, called _Page Objects_. -This means that we have built an abstraction for all GitLab pages that we use +This means that we have built an abstraction for all pages in GitLab that we use to drive GitLab QA scenarios. Whenever we do something on a page, like filling in a form, or clicking a button, we do that only through a page object associated with this area of GitLab. diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md index f91fc3115d7..129876f0c8e 100644 --- a/doc/development/testing_guide/flaky_tests.md +++ b/doc/development/testing_guide/flaky_tests.md @@ -61,7 +61,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224> - FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!): - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015> - - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944> + - [Transient failure in `spec/requests/api/commits_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944> - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184> - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404> diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index 2d33f3102b6..314995ca9b3 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -482,7 +482,7 @@ As long as the fixtures don't change, `yarn test` is sufficient (and saves you s While developing locally, it may be helpful to keep Karma running so that you can get instant feedback on as you write tests and modify code. To do this -you can start Karma with `yarn run karma-start`. It will compile the javascript +you can start Karma with `yarn run karma-start`. It will compile the JavaScript assets and run a server at `http://localhost:9876/` where it will automatically run the tests on any browser which connects to it. You can enter that url on multiple browsers at once to have it run the tests on each in parallel. diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md index 50571a5224d..3dd403f148e 100644 --- a/doc/development/testing_guide/review_apps.md +++ b/doc/development/testing_guide/review_apps.md @@ -142,7 +142,7 @@ their node under pressure. ### Log into my Review App The default username is `root` and its password can be found in the 1Password -secure note named **gitlab-{ce,ee} Review App's root password**. +secure note named `gitlab-{ce,ee} Review App's root password`. ### Enable a feature flag for my Review App @@ -235,7 +235,7 @@ For the record, the debugging steps to find out this issue were: 1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://github.com/ahmetb/kubectx/)) 1. `kubectl get pods | grep dns` 1. `kubectl describe pod <pod name>` & confirm exact error message -1. Web search for exact error message, following rabbit hole to [a relevant kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345) +1. Web search for exact error message, following rabbit hole to [a relevant Kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345) 1. Access the node over SSH via the GCP console (**Computer Engine > VM instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs) 1. In the node: `systemctl --version` => systemd 232 diff --git a/doc/development/uploads.md b/doc/development/uploads.md index 0ceeb57266a..e3ff62f1d2f 100644 --- a/doc/development/uploads.md +++ b/doc/development/uploads.md @@ -82,7 +82,7 @@ To address this problem an HA object storage can be used and it's supported by [ Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations. -All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it. +All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it. ## How to select the proper level of acceleration? @@ -92,19 +92,19 @@ We can identify three major use-cases for an upload: 1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md). 1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development. -1. **sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS. +1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS. For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802). ### Handling repository uploads -Some features involves git repository uploads without using a regular git client. +Some features involves Git repository uploads without using a regular Git client. Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md). -Those uploads requires the rails controller to act as a git client in lieu of the user. +Those uploads requires the rails controller to act as a Git client in lieu of the user. Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size. -In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq. +In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with Sidekiq. ## Upload encodings @@ -114,7 +114,7 @@ We have three kinds of file encoding in our uploads: 1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request. 1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body. -1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires [gitlab-workhorse#226](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226) to be implemented. +1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This will require a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226). ## Uploading technologies @@ -212,7 +212,9 @@ In this setup an extra rails route needs to be implemented in order to handle au you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb) and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32). -**note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path. +NOTE: **Note:** +This will fall back to _Workhorse disk acceleration_ when object storage is not enabled +in the GitLab instance. The answer to the `/authorize` call will only contain a file system path. ```mermaid sequenceDiagram @@ -267,4 +269,4 @@ sequenceDiagram This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled. -Once the request reachs rails, it will schedule an object storage upload as a sidekiq job. +Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job. diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md index 6dcf56da4f0..5c3c2188629 100644 --- a/doc/user/project/deploy_tokens/index.md +++ b/doc/user/project/deploy_tokens/index.md @@ -71,7 +71,7 @@ To read the container registry images, you'll need to: 1. Log in to GitLab’s Container Registry using the deploy token: ```sh -docker login registry.example.com -u <username> -p <deploy_token> +docker login -u <username> -p <deploy_token> registry.example.com ``` Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index 71877fc74b1..4b13d90074f 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -290,140 +290,10 @@ 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. -## Git push options +## Use Git push options with merge requests -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) in GitLab 11.10. - -NOTE: **Note:** -Git push options are only available with Git 2.10 or newer. With Git older than 2.18 -`git push --push-option=...` should be used instead of `git push -o ...`. - -GitLab supports using -[Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) -to perform the following actions against merge requests at the same time -as pushing changes: - -- Create a new merge request for the pushed branch. -- Set the target of the merge request to a particular branch. -- Set the merge request to merge when its pipeline succeeds. -- Set the merge request to remove the source branch when it's merged. -- Set the title of the merge request to a particular title. -- Set the description of the merge request to a particular description. -- Add or remove labels from the merge request. - -### Create a new merge request using Git push options - -To create a new merge request for a branch, use the -`merge_request.create` push option: - -```sh -git push -o merge_request.create -``` - -### Set the target branch of a merge request using Git push options - -To update an existing merge request's target branch, use the -`merge_request.target=<branch_name>` push option: - -```sh -git push -o merge_request.target=branch_name -``` - -You can also create a merge request and set its target branch at the -same time using a `-o` flag per push option: - -```sh -git push -o merge_request.create -o merge_request.target=branch_name -``` - -### Set merge when pipeline succeeds using Git push options - -To set an existing merge request to -[merge when its pipeline succeeds](merge_when_pipeline_succeeds.md), use -the `merge_request.merge_when_pipeline_succeeds` push option: - -```sh -git push -o merge_request.merge_when_pipeline_succeeds -``` - -You can also create a merge request and set it to merge when its -pipeline succeeds at the same time using a `-o` flag per push option: - -```sh -git push -o merge_request.create -o merge_request.merge_when_pipeline_succeeds -``` - -### Set removing the source branch using Git push options - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2. - -To set an existing merge request to remove the source branch when the -merge request is merged, the -`merge_request.remove_source_branch` push option can be used: - -```sh -git push -o merge_request.remove_source_branch -``` - -You can also use this push option in addition to the -`merge_request.create` push option. - -### Set merge request title using Git push options - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2. - -To set the title of an existing merge request, use -the `merge_request.title` push option: - -```sh -git push -o merge_request.title="The title I want" -``` - -You can also use this push option in addition to the -`merge_request.create` push option. - -### Set merge request description using Git push options - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2. - -To set the description of an existing merge request, use -the `merge_request.description` push option: - -```sh -git push -o merge_request.description="The description I want" -``` - -You can also use this push option in addition to the -`merge_request.create` push option. - -### Add or remove labels using Git push options - -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) in GitLab 12.3. - -You can add or remove labels from merge requests using push options. - -For example, to add two labels to an existing merge request, use the -`merge_request.label` push option: - -```sh -git push -o merge_request.label="label1" -o merge_request.label="label2" -``` - -To remove two labels from an existing merge request, use -the `merge_request.unlabel` push option: - -```sh -git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2" -``` - -You can also use these push options in addition to the -`merge_request.create` push option. - -To create a merge request and add two labels to it, use: - -```sh -git push -o merge_request.create -o merge_request.label="label1" -o merge_request.label="label2" -``` +Use [Git push options](../push_options.md) to create or update merge requests when +pushing changes to GitLab with Git, without needing to use the GitLab interface. ## Find the merge request that introduced a change diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md index 527bffdd91f..8a328c025ff 100644 --- a/doc/user/project/merge_requests/merge_request_approvals.md +++ b/doc/user/project/merge_requests/merge_request_approvals.md @@ -66,13 +66,7 @@ suitable to your workflow: ## Editing approvals **(PREMIUM)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8. - -CAUTION: **Caution:** -There was a [regression affecting this feature in 11.8](https://gitlab.com/gitlab-org/gitlab/merge_requests/9648). We recommend upgrading _at least_ to version 11.8.2. to avoid any issues. - -NOTE: **Note:** -In 11.8 this feature does not work in [private groups](https://gitlab.com/gitlab-org/gitlab/issues/10356). +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. For GitLab Premium, [multiple approver rules](#multiple-approval-rules-premium) can be configured. To configure the merge request approval rules: @@ -87,7 +81,7 @@ request approval rules: ## Multiple approval rules **(PREMIUM)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. For GitLab Premium, a merge request's overall approval status is determined by a set of rules. Each rule contains: diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md new file mode 100644 index 00000000000..51c46dbd1d4 --- /dev/null +++ b/doc/user/project/push_options.md @@ -0,0 +1,77 @@ +--- +type: reference +--- + +# Push Options + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15643) in GitLab 11.7. + +GitLab supports using [Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) +to perform various actions at the same time as pushing changes. + +Currently, there are push options available for: + +- [Skipping CI jobs](#push-options-for-gitlab-cicd) +- [Merge requests](#push-options-for-merge-requests) + +NOTE: **Note:** +Git push options are only available with Git 2.10 or newer. + +For Git versions 2.10 to 2.17 use `--push-option`: + +```shell +git push --push-option=<push_option> +``` + +For version 2.18 and later, you can use the above format, or the shorter `-o`: + +```shell +git push -o <push_option> +``` + +## Push options for GitLab CI/CD + +If the `ci.skip` push option is used, the commit will be pushed, but no [CI pipeline](../../ci/pipelines.md) +will be created. + +| Push option | Description | +| ----------- | ----------- | +| `ci.skip` | Do not create a CI pipeline for the latest push. | + +For example: + +```shell +git push -o ci.skip +``` + +## Push options for merge requests + +You can use Git push options to perform certain actions for merge requests at the same +time as pushing changes: + +| Push option | Description | Introduced in version | +| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------- | +| `merge_request.create` | Create a new merge request for the pushed branch. | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) | +| `merge_request.target=<branch_name>` | Set the target of the merge request to a particular branch. | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) | +| `merge_request.merge_when_pipeline_succeeds` | Set the merge request to [merge when its pipeline succeeds](merge_requests/merge_when_pipeline_succeeds.md). | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) | +| `merge_request.remove_source_branch` | Set the merge request to remove the source branch when it's merged. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) | +| `merge_request.title="<title>"` | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) | +| `merge_request.description="<description>"` | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) | +| `merge_request.label="<label>"` | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) | +| `merge_request.unlabel="<label>"` | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) | + +If you use a push option that requires text with spaces in it, you need to enclose it +in quotes (`"`). You can omit the quotes if there are no spaces. Some examples: + +```shell +git push -o merge_request.label="Label with spaces" +git push -o merge_request.label=Label-with-no-spaces +``` + +You can combine push options to accomplish multiple tasks at once, by using +multiple `-o` (or `--push-option`) flags. For example, if you want to create a new +merge request, and target a branch named `my-target-branch`: + +```shell +git push -o merge_request.create -o merge_request.target=my-target-branch +``` |
