diff options
90 files changed, 505 insertions, 498 deletions
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 833c1f367dd..987a0b9f350 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -545,10 +545,10 @@ discussed in [Redis setup overview](#redis-setup-overview) and Here is a list and description of each **machine** and the assigned **IP**: -* `10.0.0.1`: Redis Master + Sentinel 1 -* `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.3`: Redis Slave 2 + Sentinel 3 -* `10.0.0.4`: GitLab application +- `10.0.0.1`: Redis Master + Sentinel 1 +- `10.0.0.2`: Redis Slave 1 + Sentinel 2 +- `10.0.0.3`: Redis Slave 2 + Sentinel 3 +- `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 2101d36d2b6..14e2784c419 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -214,10 +214,10 @@ For this example, **Sentinel 1** will be configured in the same machine as the Here is a list and description of each **machine** and the assigned **IP**: -* `10.0.0.1`: Redis Master + Sentinel 1 -* `10.0.0.2`: Redis Slave 1 + Sentinel 2 -* `10.0.0.3`: Redis Slave 2 + Sentinel 3 -* `10.0.0.4`: GitLab application +- `10.0.0.1`: Redis Master + Sentinel 1 +- `10.0.0.2`: Redis Slave 1 + Sentinel 2 +- `10.0.0.3`: Redis Slave 2 + Sentinel 3 +- `10.0.0.4`: GitLab application Please note that after the initial configuration, if a failover is initiated by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master** diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index bb621b788f1..058346df56d 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -17,19 +17,18 @@ The housekeeping function will run a `repack` or `gc` depending on the For example in the following scenario a `git repack -d` will be executed: -+ Project: pushes since gc counter (`pushes_since_gc`) = `10` -+ Git GC period = `200` -+ Full repack period = `50` +- Project: pushes since gc counter (`pushes_since_gc`) = `10` +- Git GC period = `200` +- Full repack period = `50` When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when the `pushes_since_gc` value is 200 a `git gc` will be run. -+ `git gc` ([man page][man-gc]) runs a number of housekeeping tasks, -such as compressing filerevisions (to reduce disk space and increase performance) -and removing unreachable objects which may have been created from prior invocations of -`git add`. - -+ `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack. +- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks, + such as compressing filerevisions (to reduce disk space and increase performance) + and removing unreachable objects which may have been created from prior invocations of + `git add`. +- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack. You can find this option under your **[Project] > Edit Project**. @@ -39,4 +38,4 @@ You can find this option under your **[Project] > Edit Project**. [ce-2371]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2371 "Housekeeping merge request" [man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page" -[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
\ No newline at end of file +[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md index fa58d0ef15f..06ef6988014 100644 --- a/doc/administration/integration/terminal.md +++ b/doc/administration/integration/terminal.md @@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md). In brief: -* GitLab relies on the user to provide their own Kubernetes credentials, and to +- GitLab relies on the user to provide their own Kubernetes credentials, and to appropriately label the pods they create when deploying. -* When a user navigates to the terminal page for an environment, they are served +- When a user navigates to the terminal page for an environment, they are served a JavaScript application that opens a WebSocket connection back to GitLab. -* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), +- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse), rather than the Rails application server. -* Workhorse queries Rails for connection details and user permissions; Rails - queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md) -* Workhorse acts as a proxy server between the user's browser and the Kubernetes +- Workhorse queries Rails for connection details and user permissions. Rails + queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md). +- Workhorse acts as a proxy server between the user's browser and the Kubernetes API, passing WebSocket frames between the two. -* Workhorse regularly polls Rails, terminating the WebSocket connection if the +- Workhorse regularly polls Rails, terminating the WebSocket connection if the user no longer has permission to access the terminal, or if the connection details have changed. @@ -40,10 +40,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in front of GitLab, you may need to make some changes to your configuration. These guides document the necessary steps for a selection of popular reverse proxies: -* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) -* [NGINX](https://www.nginx.com/blog/websocket-nginx/) -* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) -* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) +- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) +- [NGINX](https://www.nginx.com/blog/websocket-nginx/) +- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/) +- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html) Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so it's safe to enable support for these headers globally. If you'd rather had a @@ -60,8 +60,8 @@ the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse proxy in the chain. For most users, this will be the NGINX server bundled with Omnibus GitLab, in which case, you need to: -* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file -* Ensure the whole block is uncommented, and then comment out or remove the +- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file +- Ensure the whole block is uncommented, and then comment out or remove the `Connection` and `Upgrade` lines. For your own load balancer, just reverse the configuration changes recommended diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index 0ca1d77f1d0..d8f80965c21 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -52,9 +52,9 @@ and these checks will verify them against current files. Currently, integrity checks are supported for the following types of file: -* CI artifacts (Available from version 10.7.0) -* LFS objects (Available from version 10.6.0) -* User uploads (Available from version 10.6.0) +- CI artifacts (Available from version 10.7.0) +- LFS objects (Available from version 10.6.0) +- User uploads (Available from version 10.6.0) **Omnibus Installation** diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index 12238ba7b32..51e1518d73f 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -7,8 +7,8 @@ Legacy Storage is the storage behavior prior to version 10.0. For historical reasons, GitLab replicated the same mapping structure from the projects URLs: -* Project's repository: `#{namespace}/#{project_name}.git` -* Project's wiki: `#{namespace}/#{project_name}.wiki.git` +- Project's repository: `#{namespace}/#{project_name}.git` +- Project's wiki: `#{namespace}/#{project_name}.wiki.git` This structure made it simple to migrate from existing solutions to GitLab and easy for Administrators to find where the repository is stored. diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index 643c5b9fe80..bd702dcc9ec 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause. # More information -* [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/) -* [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt) +- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/) +- [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt) diff --git a/doc/api/lint.md b/doc/api/lint.md index c37a8bff749..a0307f7081d 100644 --- a/doc/api/lint.md +++ b/doc/api/lint.md @@ -20,7 +20,7 @@ Be sure to copy paste the exact contents of `.gitlab-ci.yml` as YAML is very pic Example responses: -* Valid content: +- Valid content: ```json { @@ -29,7 +29,7 @@ Example responses: } ``` -* Invalid content: +- Invalid content: ```json { @@ -40,7 +40,7 @@ Example responses: } ``` -* Without the content attribute: +- Without the content attribute: ```json { @@ -49,4 +49,3 @@ Example responses: ``` [ce-5953]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5953 - diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md index 8a1e6b52092..6786c0c5b5c 100644 --- a/doc/api/oauth2.md +++ b/doc/api/oauth2.md @@ -1,33 +1,33 @@ # GitLab as an OAuth2 provider -This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf. +This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf. If you want GitLab to be an OAuth authentication service provider to sign into other services please see the [OAuth2 provider](../integration/oauth_provider.md) documentation. -This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper). +This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper). ## Supported OAuth2 Flows -GitLab currently supports following authorization flows: +GitLab currently supports following authorization flows: -* *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side. -* *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages). -* *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services. +- *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side. +- *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages). +- *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services. Please refer to [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out in details how all those flows work and pick the right one for your use case. -Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page -in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation +Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page +in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation you'll obtain `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**. ->**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique -value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should +>**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique +value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should have been a requirement in the standard! -In the following sections you will find detailed instructions on how to obtain authorization with each flow. +In the following sections you will find detailed instructions on how to obtain authorization with each flow. -### Web Application Flow +### Web Application Flow Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.1) for a detailed flow description @@ -48,7 +48,7 @@ You should then use the `code` to request an access token. #### 2. Requesting access token -Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example, +Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example, we are using Ruby's `rest-client`: ``` @@ -73,13 +73,13 @@ You can now make requests to the API with the access token returned. Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.2) for a detailed flow description. -Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret -or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily. +Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret +or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily. + +>**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id` +associated with access token before granting access to the data +(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)). ->**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id` -associated with access token before granting access to the data -(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)). - #### 1. Requesting access token @@ -89,7 +89,7 @@ To request the access token, you should redirect the user to the `/oauth/authori https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH ``` -This will ask the user to approve the applications access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect +This will ask the user to approve the application's access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect will include a fragment with `access_token` as well as token details in GET parameters, for example: ``` @@ -100,7 +100,7 @@ http://myapp.com/oauth/redirect#access_token=ABCDExyz123&state=YOUR_UNIQUE_STATE Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.3) for a detailed flow description. -> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication +> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication turned on. These users can access the API using [personal access tokens] instead. In this flow, a token is requested in exchange for the resource owner credentials (username and password). @@ -109,7 +109,7 @@ client is part of the device operating system or a highly privileged application available (such as an authorization code). >**Important:** -Never store the users credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens] +Never store the user's credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens] are a better choice. Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used @@ -148,7 +148,7 @@ puts access_token.token ## Access GitLab API with `access token` -The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter +The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter ``` GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN ``` @@ -160,4 +160,4 @@ curl --header "Authorization: Bearer OAUTH-TOKEN" https://gitlab.example.com/api ``` [personal access tokens]: ../user/profile/personal_access_tokens.md -[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow
\ No newline at end of file +[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow diff --git a/doc/api/projects.md b/doc/api/projects.md index 465b1494b2a..538cd34de43 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -7,30 +7,29 @@ This is determined by the `visibility` field in the project. Values for the project visibility level are: -* `private`: +- `private`: Project access must be granted explicitly for each user. -* `internal`: +- `internal`: The project can be cloned by any logged in user. -* `public`: +- `public`: The project can be cloned without any authentication. ## Project merge method There are currently three options for `merge_method` to choose from: -* `merge`: +- `merge`: A merge commit is created for every merge, and merging is allowed as long as there are no conflicts. -* `rebase_merge`: +- `rebase_merge`: A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible. This way you could make sure that if this merge request would build, after merging to target branch it would also build. -* `ff`: +- `ff`: No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. - ## List all projects Get a list of all visible projects across GitLab for the authenticated user. diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md index f8cf9de9aff..d2a00b9218d 100644 --- a/doc/ci/pipelines.md +++ b/doc/ci/pipelines.md @@ -241,9 +241,9 @@ So each job would be represented as a `Period`, which consists of `Period#first` as when the job started and `Period#last` as when the job was finished. A simple example here would be: -* A (1, 3) -* B (2, 4) -* C (6, 7) +- A (1, 3) +- B (2, 4) +- C (6, 7) Here A begins from 1, and ends to 3. B begins from 2, and ends to 4. C begins from 6, and ends to 7. Visually it could be viewed as: diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 98542c7e82c..efee2852eb8 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -332,10 +332,10 @@ jobs are created: There are a few rules that apply to the usage of job policy: -* `only` and `except` are inclusive. If both `only` and `except` are defined +- `only` and `except` are inclusive. If both `only` and `except` are defined in a job specification, the ref is filtered by `only` and `except`. -* `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)). -* `only` and `except` allow to specify a repository path to filter jobs for +- `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)). +- `only` and `except` allow to specify a repository path to filter jobs for forks. In addition, `only` and `except` allow the use of special keywords: diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md index d1d2b8c4907..c47ce0f1182 100644 --- a/doc/development/adding_database_indexes.md +++ b/doc/development/adding_database_indexes.md @@ -113,9 +113,9 @@ the meaning of the various columns can be found at Because the output of this query relies on the actual usage of your database it may be affected by factors such as (but not limited to): -* Certain queries never being executed, thus not being able to use certain +- Certain queries never being executed, thus not being able to use certain indexes. -* Certain tables having little data, resulting in PostgreSQL using sequence +- Certain tables having little data, resulting in PostgreSQL using sequence scans instead of index scans. In other words, this data is only reliable for a frequently used database with diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md index dd4a9e058d7..642dac614c7 100644 --- a/doc/development/background_migrations.md +++ b/doc/development/background_migrations.md @@ -25,9 +25,9 @@ should only be used for data migrations. Some examples where background migrations can be useful: -* Migrating events from one table to multiple separate tables. -* Populating one column based on JSON stored in another column. -* Migrating data that depends on the output of external services (e.g. an API). +- Migrating events from one table to multiple separate tables. +- Populating one column based on JSON stored in another column. +- Migrating data that depends on the output of external services (e.g. an API). ## Isolation diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index 9dffca5b99c..7ac846e4c4d 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -97,28 +97,28 @@ When your code contains more than 500 changes, any major breaking changes, or an This [documentation](issue_workflow.md) outlines the current issue process. -* [Type labels](issue_workflow.md#type-labels) -* [Subject labels](issue_workflow.md#subject-labels) -* [Team labels](issue_workflow.md#team-labels) -* [Release Scoping labels](issue_workflow.md#release-scoping-labels) -* [Priority labels](issue_workflow.md#priority-labels) -* [Severity labels](issue_workflow.md#severity-labels) -* [Label for community contributors](issue_workflow.md#label-for-community-contributors) -* [Issue triaging](issue_workflow.md#issue-triaging) -* [Feature proposals](issue_workflow.md#feature-proposals) -* [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines) -* [Issue weight](issue_workflow.md#issue-weight) -* [Regression issues](issue_workflow.md#regression-issues) -* [Technical and UX debt](issue_workflow.md#technical-and-ux-debt) -* [Stewardship](issue_workflow.md#stewardship) +- [Type labels](issue_workflow.md#type-labels) +- [Subject labels](issue_workflow.md#subject-labels) +- [Team labels](issue_workflow.md#team-labels) +- [Release Scoping labels](issue_workflow.md#release-scoping-labels) +- [Priority labels](issue_workflow.md#priority-labels) +- [Severity labels](issue_workflow.md#severity-labels) +- [Label for community contributors](issue_workflow.md#label-for-community-contributors) +- [Issue triaging](issue_workflow.md#issue-triaging) +- [Feature proposals](issue_workflow.md#feature-proposals) +- [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines) +- [Issue weight](issue_workflow.md#issue-weight) +- [Regression issues](issue_workflow.md#regression-issues) +- [Technical and UX debt](issue_workflow.md#technical-and-ux-debt) +- [Stewardship](issue_workflow.md#stewardship) ## Merge requests This [documentation](merge_request_workflow.md) outlines the current merge request process. -* [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines) -* [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria) -* [Definition of done](merge_request_workflow.md#definition-of-done) +- [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines) +- [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria) +- [Definition of done](merge_request_workflow.md#definition-of-done) ## Style guides diff --git a/doc/development/fe_guide/components.md b/doc/development/fe_guide/components.md index 0e9126ee667..52462a4bec9 100644 --- a/doc/development/fe_guide/components.md +++ b/doc/development/fe_guide/components.md @@ -1,18 +1,19 @@ # Components ## Contents -* [Dropdowns](#dropdowns) -* [Modals](#modals) + +- [Dropdowns](#dropdowns) +- [Modals](#modals) ## Dropdowns See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns). ### 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 - ```Haml .dropdown.my-dropdown %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false } diff --git a/doc/development/fe_guide/droplab/droplab.md b/doc/development/fe_guide/droplab/droplab.md index ce96a9fc8ae..e6aa0be671f 100644 --- a/doc/development/fe_guide/droplab/droplab.md +++ b/doc/development/fe_guide/droplab/droplab.md @@ -177,28 +177,28 @@ droplab.init().addData('trigger', [{ DropLab adds some CSS classes to help lower the barrier to integration. -For example, +For example: -* The `droplab-item-selected` css class is added to items that have been selected -either by a mouse click or by enter key selection. -* The `droplab-item-active` css class is added to items that have been selected -using arrow key navigation. -* You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example, -an `<li class="divider"></li>` list divider element that should not be interactive. +- The `droplab-item-selected` css class is added to items that have been selected + either by a mouse click or by enter key selection. +- The `droplab-item-active` css class is added to items that have been selected + using arrow key navigation. +- You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example, + an `<li class="divider"></li>` list divider element that should not be interactive. ## Internal events DropLab uses some custom events to help lower the barrier to integration. -For example, +For example: -* The `click.dl` event is fired when an `li` list item has been clicked. It is also -fired when a list item has been selected with the keyboard. It is also fired when a -`HookButton` button is clicked (a registered `button` tag or `a` tag trigger). -* The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event. -* The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event. -* The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event. -* The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event. +- The `click.dl` event is fired when an `li` list item has been clicked. It is also + fired when a list item has been selected with the keyboard. It is also fired when a + `HookButton` button is clicked (a registered `button` tag or `a` tag trigger). +- The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event. +- The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event. +- The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event. +- The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event. These custom events add a `detail` object to the vanilla `Event` object that provides some potentially useful data. @@ -233,9 +233,9 @@ droplab.init(trigger, list, [droplabAjax], { ### Documentation -* [Ajax plugin](plugins/ajax.md) -* [Filter plugin](plugins/filter.md) -* [InputSetter plugin](plugins/input_setter.md) +- [Ajax plugin](plugins/ajax.md) +- [Filter plugin](plugins/filter.md) +- [InputSetter plugin](plugins/input_setter.md) ### Development diff --git a/doc/development/fe_guide/droplab/plugins/ajax.md b/doc/development/fe_guide/droplab/plugins/ajax.md index 9c7e56fa448..b6a883ce6c4 100644 --- a/doc/development/fe_guide/droplab/plugins/ajax.md +++ b/doc/development/fe_guide/droplab/plugins/ajax.md @@ -8,10 +8,10 @@ Add the `Ajax` object to the plugins array of a `DropLab.prototype.init` or `Dro `Ajax` requires 2 config values, the `endpoint` and `method`. -* `endpoint` should be a URL to the request endpoint. -* `method` should be `setData` or `addData`. -* `setData` completely replaces the dropdown with the response data. -* `addData` appends the response data to the current dropdown list. +- `endpoint` should be a URL to the request endpoint. +- `method` should be `setData` or `addData`. +- `setData` completely replaces the dropdown with the response data. +- `addData` appends the response data to the current dropdown list. ```html <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a> diff --git a/doc/development/fe_guide/droplab/plugins/filter.md b/doc/development/fe_guide/droplab/plugins/filter.md index 0853ea4d320..ddc6a3386c7 100644 --- a/doc/development/fe_guide/droplab/plugins/filter.md +++ b/doc/development/fe_guide/droplab/plugins/filter.md @@ -7,8 +7,8 @@ to the dropdown using a simple fuzzy string search of an input value. Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call. -* `Filter` requires a config value for `template`. -* `template` should be the key of the objects within your data array that you want to compare +- `Filter` requires a config value for `template`. +- `template` should be the key of the objects within your data array that you want to compare to the user input string, for filtering. ```html diff --git a/doc/development/fe_guide/droplab/plugins/input_setter.md b/doc/development/fe_guide/droplab/plugins/input_setter.md index 94f3c8254a8..8e28a41f32e 100644 --- a/doc/development/fe_guide/droplab/plugins/input_setter.md +++ b/doc/development/fe_guide/droplab/plugins/input_setter.md @@ -6,9 +6,9 @@ Add the `InputSetter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call. -* `InputSetter` requires a config value for `input` and `valueAttribute`. -* `input` should be the DOM element that you want to manipulate. -* `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value +- `InputSetter` requires a config value for `input` and `valueAttribute`. +- `input` should be the DOM element that you want to manipulate. +- `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value to update the `input` element with. You can also set the `InputSetter` config to an array of objects, which will allow you to update multiple elements. diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md index cca3ad6fae6..ad87ecf1b87 100644 --- a/doc/development/fe_guide/index.md +++ b/doc/development/fe_guide/index.md @@ -118,7 +118,7 @@ The [externalization part of the guide](../i18n/externalization.md) explains the ## [DropLab](droplab/droplab.md) Our internal `DropLab` dropdown library. -* [DropLab](droplab/droplab.md) -* [Ajax plugin](droplab/plugins/ajax.md) -* [Filter plugin](droplab/plugins/filter.md) -* [InputSetter plugin](droplab/plugins/input_setter.md) +- [DropLab](droplab/droplab.md) +- [Ajax plugin](droplab/plugins/ajax.md) +- [Filter plugin](droplab/plugins/filter.md) +- [InputSetter plugin](droplab/plugins/input_setter.md) diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md index ef0eed786d2..e5a383c25f5 100644 --- a/doc/development/fe_guide/performance.md +++ b/doc/development/fe_guide/performance.md @@ -29,8 +29,8 @@ To improve the time to first render we are using lazy loading for images. This w the actual image source on the `data-src` attribute. After the HTML is rendered and JavaScript is loaded, the value of `data-src` will be moved to `src` automatically if the image is in the current viewport. -* Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy` -* If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided. +- Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy`. +- If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided. If you are asynchronously adding content which contains lazy images then you need to call the function `gl.lazyLoader.searchLazyImages()` which will search for lazy images and load them if needed. diff --git a/doc/development/file_storage.md b/doc/development/file_storage.md index 6e014e8c751..b90dc90e424 100644 --- a/doc/development/file_storage.md +++ b/doc/development/file_storage.md @@ -4,15 +4,15 @@ We use the [CarrierWave] gem to handle file upload, store and retrieval. There are many places where file uploading is used, according to contexts: -* System +- System - Instance Logo (logo visible in sign in/sign up pages) - Header Logo (one displayed in the navigation bar) -* Group +- Group - Group avatars -* User +- User - User avatars - User snippet attachments -* Project +- Project - Project avatars - Issues/MR/Notes Markdown attachments - Issues/MR/Notes Legacy Markdown attachments @@ -52,7 +52,7 @@ hash of the project ID instead, if project migrates to the new approach (introdu ### Path segments -Files are stored at multiple locations and use different path schemes. +Files are stored at multiple locations and use different path schemes. All the `GitlabUploader` derived classes should comply with this path segment schema: ``` @@ -61,7 +61,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc | `<gitlab_root>/public/` | `uploads/-/system/` | `user/avatar/:id/` | `:filename` | | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- | | `CarrierWave.root` | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment` | `CarrierWave::Uploader#filename` | -| | `CarrierWave::Uploader#store_dir` | | +| | `CarrierWave::Uploader#store_dir` | | | FileUploader | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- | @@ -69,7 +69,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc | `<gitlab_root>/shared/` | `snippets/` | `:secret/` | `:filename` | | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- | | `CarrierWave.root` | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment` | `CarrierWave::Uploader#filename` | -| | `CarrierWave::Uploader#store_dir` | | +| | `CarrierWave::Uploader#store_dir` | | | | | `FileUploader#upload_path | | ObjectStore::Concern (store = remote) @@ -77,7 +77,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc | `<bucket_name>` | <ignored> | `user/avatar/:id/` | `:filename` | | ----------------------- + ------------------------- + ----------------------------------- + -------------------------------- | | `#fog_dir` | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment` | `CarrierWave::Uploader#filename` | -| | | `ObjectStorage::Concern#store_dir` | | +| | | `ObjectStorage::Concern#store_dir` | | | | | `ObjectStorage::Concern#upload_path | ``` diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md index 863ac049db6..5445f36b9fa 100644 --- a/doc/development/github_importer.md +++ b/doc/development/github_importer.md @@ -13,20 +13,20 @@ or Rake tasks. The parallel importer on the other hand uses Sidekiq. ## Requirements -* GitLab CE 10.2.0 or newer. -* Sidekiq workers that process the `github_importer` and +- GitLab CE 10.2.0 or newer. +- Sidekiq workers that process the `github_importer` and `github_importer_advance_stage` queues (this is enabled by default). -* Octokit (used for interacting with the GitHub API) +- Octokit (used for interacting with the GitHub API). ## Code structure The importer's codebase is broken up into the following directories: -* `lib/gitlab/github_import`: this directory contains most of the code such as +- `lib/gitlab/github_import`: this directory contains most of the code such as the classes used for importing resources. -* `app/workers/gitlab/github_import`: this directory contains the Sidekiq +- `app/workers/gitlab/github_import`: this directory contains the Sidekiq workers. -* `app/workers/concerns/gitlab/github_import`: this directory contains a few +- `app/workers/concerns/gitlab/github_import`: this directory contains a few modules reused by the various Sidekiq workers. ## Architecture overview @@ -188,8 +188,8 @@ projects get imported the fewer GitHub API calls will be needed. The code for this resides in: -* `lib/gitlab/github_import/user_finder.rb` -* `lib/gitlab/github_import/caching.rb` +- `lib/gitlab/github_import/user_finder.rb` +- `lib/gitlab/github_import/caching.rb` ## Mapping labels and milestones @@ -204,6 +204,6 @@ project that is being imported. The code for this resides in: -* `lib/gitlab/github_import/label_finder.rb` -* `lib/gitlab/github_import/milestone_finder.rb` -* `lib/gitlab/github_import/caching.rb` +- `lib/gitlab/github_import/label_finder.rb` +- `lib/gitlab/github_import/milestone_finder.rb` +- `lib/gitlab/github_import/caching.rb` diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md index a5a34d82bec..1b9ebb50c29 100644 --- a/doc/development/gotchas.md +++ b/doc/development/gotchas.md @@ -96,8 +96,8 @@ end ### Why -* Because it is not isolated therefore it might be broken at times. -* Because it doesn't work whenever the method we want to stub was defined +- Because it is not isolated therefore it might be broken at times. +- Because it doesn't work whenever the method we want to stub was defined in a prepended module, which is very likely the case in EE. We could see error like this: diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md index a36dc6424a7..5f95cf3707c 100644 --- a/doc/development/instrumentation.md +++ b/doc/development/instrumentation.md @@ -11,12 +11,12 @@ Instrumenting methods is done by using the `Gitlab::Metrics::Instrumentation` module. This module offers a few different methods that can be used to instrument code: -* `instrument_method`: instruments a single class method. -* `instrument_instance_method`: instruments a single instance method. -* `instrument_class_hierarchy`: given a Class this method will recursively +- `instrument_method`: instruments a single class method. +- `instrument_instance_method`: instruments a single instance method. +- `instrument_class_hierarchy`: given a Class this method will recursively instrument all sub-classes (both class and instance methods). -* `instrument_methods`: instruments all public and private class methods of a Module. -* `instrument_instance_methods`: instruments all public and private instance methods of a +- `instrument_methods`: instruments all public and private class methods of a Module. +- `instrument_instance_methods`: instruments all public and private instance methods of a Module. To remove the need for typing the full `Gitlab::Metrics::Instrumentation` diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md index ee01c89e0ed..6f1baad3a2d 100644 --- a/doc/development/merge_request_performance_guidelines.md +++ b/doc/development/merge_request_performance_guidelines.md @@ -9,8 +9,8 @@ To measure the impact of a merge request you can use [Sherlock](profiling.md#sherlock). It's also highly recommended that you read the following guides: -* [Performance Guidelines](performance.md) -* [What requires downtime?](what_requires_downtime.md) +- [Performance Guidelines](performance.md) +- [What requires downtime?](what_requires_downtime.md) ## Impact Analysis diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md index 23aa318ef91..98b54684d39 100644 --- a/doc/development/migration_style_guide.md +++ b/doc/development/migration_style_guide.md @@ -40,7 +40,7 @@ migrations _unless_ schema changes are absolutely required to solve a problem. ## What Requires Downtime? The document ["What Requires Downtime?"](what_requires_downtime.md) specifies -various database operations, such as +various database operations, such as - [adding, dropping, and renaming columns](what_requires_downtime.md#adding-columns) - [changing column constraints and types](what_requires_downtime.md#changing-column-constraints) @@ -59,9 +59,9 @@ the migrations that _do_ require downtime. To tag a migration, add the following two constants to the migration class' body: -* `DOWNTIME`: a boolean that when set to `true` indicates the migration requires +- `DOWNTIME`: a boolean that when set to `true` indicates the migration requires downtime. -* `DOWNTIME_REASON`: a String containing the reason for the migration requiring +- `DOWNTIME_REASON`: a String containing the reason for the migration requiring downtime. This constant **must** be set when `DOWNTIME` is set to `true`. For example: @@ -318,8 +318,8 @@ end Instead of using these methods one should use the following methods to store timestamps with timezones: -* `add_timestamps_with_timezone` -* `timestamps_with_timezone` +- `add_timestamps_with_timezone` +- `timestamps_with_timezone` This ensures all timestamps have a time zone specified. This in turn means existing timestamps won't suddenly use a different timezone when the system's timezone changes. It also makes it very clear which diff --git a/doc/development/new_fe_guide/development/components.md b/doc/development/new_fe_guide/development/components.md index 899efb398cd..8ae58d30c35 100644 --- a/doc/development/new_fe_guide/development/components.md +++ b/doc/development/new_fe_guide/development/components.md @@ -6,16 +6,16 @@ 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) +- [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). D3 is very popular across many projects outside of GitLab: -* [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html) -* [plot.ly](https://plot.ly/) -* [Droptask](https://www.droptask.com/) +- [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html) +- [plot.ly](https://plot.ly/) +- [Droptask](https://www.droptask.com/) Within GitLab, D3 has been used for the following notable features -* [Prometheus graphs](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) -* Contribution calendars +- [Prometheus graphs](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html) +- Contribution calendars diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md index 5ccd5357314..640a8d64176 100644 --- a/doc/development/new_fe_guide/development/performance.md +++ b/doc/development/new_fe_guide/development/performance.md @@ -7,10 +7,10 @@ We have a performance dashboard available in one of our [grafana instances](http 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/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 +There are 3 recommended high impact metrics to review on each page: -* [First visual change](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint) -* [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) -* [Visual Complete 95%](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) +- [First visual change](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint) +- [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) +- [Visual Complete 95%](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index) For these metrics, lower numbers are better as it means that the website is more performant. diff --git a/doc/development/new_fe_guide/development/testing.md b/doc/development/new_fe_guide/development/testing.md index 0d98180add0..310640f0a01 100644 --- a/doc/development/new_fe_guide/development/testing.md +++ b/doc/development/new_fe_guide/development/testing.md @@ -20,8 +20,8 @@ These have been removed from our codebase in May 2018 ([#23036](https://gitlab.c See also: -- [old testing guide](../../testing_guide/frontend_testing.html) -- [notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components) +- [Old testing guide](../../testing_guide/frontend_testing.html). +- [Notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components). [#53757]: https://gitlab.com/gitlab-org/gitlab-ce/issues/53757 @@ -302,8 +302,8 @@ Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts To make mounting a Vue component easier and more readable, we have a few helpers available in `spec/helpers/vue_mount_component_helper`. -* `createComponentWithStore` -* `mountComponentWithStore` +- `createComponentWithStore` +- `mountComponentWithStore` Examples of usage: diff --git a/doc/development/new_fe_guide/modules/index.md b/doc/development/new_fe_guide/modules/index.md index 0a7f2dbd819..a7820442df0 100644 --- a/doc/development/new_fe_guide/modules/index.md +++ b/doc/development/new_fe_guide/modules/index.md @@ -1,5 +1,5 @@ # Modules -* [DirtySubmit](dirty_submit.md) +- [DirtySubmit](dirty_submit.md) - Disable form submits until there are unsaved changes.
\ No newline at end of file + Disable form submits until there are unsaved changes. diff --git a/doc/development/performance.md b/doc/development/performance.md index 4cc2fdc9a58..972c93be817 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -23,9 +23,9 @@ The process of solving performance problems is roughly as follows: When providing timings make sure to provide: -* The 95th percentile -* The 99th percentile -* The mean +- The 95th percentile +- The 99th percentile +- The mean When providing screenshots of graphs, make sure that both the X and Y axes and the legend are clearly visible. If you happen to have access to GitLab.com's own @@ -36,12 +36,12 @@ graphs/dashboards. GitLab provides built-in tools to help improve performance and availability: -* [Profiling](profiling.md) - * [Sherlock](profiling.md#sherlock) -* [GitLab Performance Monitoring](../administration/monitoring/performance/index.md) -* [Request Profiling](../administration/monitoring/performance/request_profiling.md) -* [QueryRecoder](query_recorder.md) for preventing `N+1` regressions -* [Chaos endpoints](chaos_endpoints.md) for testing failure scenarios. Intended mainly for testing availability. +- [Profiling](profiling.md). + - [Sherlock](profiling.md#sherlock). +- [GitLab Performance Monitoring](../administration/monitoring/performance/index.md). +- [Request Profiling](../administration/monitoring/performance/request_profiling.md). +- [QueryRecoder](query_recorder.md) for preventing `N+1` regressions. +- [Chaos endpoints](chaos_endpoints.md) for testing failure scenarios. Intended mainly for testing availability. GitLab employees can use GitLab.com's performance monitoring systems located at <https://dashboards.gitlab.net>, this requires you to log in using your @@ -269,11 +269,11 @@ piece of code is worth optimizing. The only two things you can do are: Some examples of changes that aren't really important/worth the effort: -* Replacing double quotes with single quotes. -* Replacing usage of Array with Set when the list of values is very small. -* Replacing library A with library B when both only take up 0.1% of the total +- Replacing double quotes with single quotes. +- Replacing usage of Array with Set when the list of values is very small. +- Replacing library A with library B when both only take up 0.1% of the total execution time. -* Calling `freeze` on every string (see [String Freezing](#string-freezing)). +- Calling `freeze` on every string (see [String Freezing](#string-freezing)). ## Slow Operations & Sidekiq diff --git a/doc/development/policies.md b/doc/development/policies.md index 62141356f59..97424d90fb5 100644 --- a/doc/development/policies.md +++ b/doc/development/policies.md @@ -13,7 +13,7 @@ Permissions are broken into two parts: `conditions` and `rules`. Conditions are Conditions are defined by the `condition` method, and are given a name and a block. The block will be executed in the context of the policy object - so it can access `@user` and `@subject`, as well as call any methods defined on the policy. Note that `@user` may be nil (in the anonymous case), but `@subject` is guaranteed to be a real instance of the subject class. -``` ruby +```ruby class FooPolicy < BasePolicy condition(:is_public) do # @subject guaranteed to be an instance of Foo @@ -37,7 +37,7 @@ Conditions are cached according to their scope. Scope and ordering will be cover A `rule` is a logical combination of conditions and other rules, that are configured to enable or prevent certain abilities. It is important to note that the rule configuration is static - a rule's logic cannot touch the database or know about `@user` or `@subject`. This allows us to cache only at the condition level. Rules are specified through the `rule` method, which takes a block of DSL configuration, and returns an object that responds to `#enable` or `#prevent`: -``` ruby +```ruby class FooPolicy < BasePolicy # ... @@ -57,10 +57,10 @@ end Within the rule DSL, you can use: -* A regular word mentions a condition by name - a rule that is in effect when that condition is truthy. -* `~` indicates negation -* `&` and `|` are logical combinations, also available as `all?(...)` and `any?(...)` -* `can?(:other_ability)` delegates to the rules that apply to `:other_ability`. Note that this is distinct from the instance method `can?`, which can check dynamically - this only configures a delegation to another ability. +- A regular word mentions a condition by name - a rule that is in effect when that condition is truthy. +- `~` indicates negation. +- `&` and `|` are logical combinations, also available as `all?(...)` and `any?(...)`. +- `can?(:other_ability)` delegates to the rules that apply to `:other_ability`. Note that this is distinct from the instance method `can?`, which can check dynamically - this only configures a delegation to another ability. ## Scores, Order, Performance @@ -72,7 +72,7 @@ When a policy is asked whether a particular ability is allowed (`policy.allowed? Sometimes, a condition will only use data from `@user` or only from `@subject`. In this case, we want to change the scope of the caching, so that we don't recalculate conditions unnecessarily. For example, given: -``` ruby +```ruby class FooPolicy < BasePolicy condition(:expensive_condition) { @subject.expensive_query? } @@ -82,7 +82,7 @@ end Naively, if we call `Ability.can?(user1, :some_ability, foo)` and `Ability.can?(user2, :some_ability, foo)`, we would have to calculate the condition twice - since they are for different users. But if we use the `scope: :subject` option: -``` ruby +```ruby condition(:expensive_condition, scope: :subject) { @subject.expensive_query? } ``` @@ -93,7 +93,7 @@ both user and subject (including a simple anonymous check!) your result will be Sometimes we are checking permissions for a lot of users for one subject, or a lot of subjects for one user. In this case, we want to set a *preferred scope* - i.e. tell the system that we prefer rules that can be cached on the repeated parameter. For example, in `Ability.users_that_can_read_project`: -``` ruby +```ruby def users_that_can_read_project(users, project) DeclarativePolicy.subject_scope do users.select { |u| allowed?(u, :read_project, project) } @@ -105,9 +105,9 @@ This will, for example, prefer checking `project.public?` to checking `user.admi ## Delegation -Delegation is the inclusion of rules from another policy, on a different subject. For example, +Delegation is the inclusion of rules from another policy, on a different subject. For example: -``` ruby +```ruby class FooPolicy < BasePolicy delegate { @subject.project } end diff --git a/doc/development/polymorphic_associations.md b/doc/development/polymorphic_associations.md index d63b9fb115f..5d69c8add38 100644 --- a/doc/development/polymorphic_associations.md +++ b/doc/development/polymorphic_associations.md @@ -7,9 +7,9 @@ usually works by adding two columns to a table: a target type column, and a target id. For example, at the time of writing we have such a setup for `members` with the following columns: -* `source_type`: a string defining the model to use, can be either `Project` or +- `source_type`: a string defining the model to use, can be either `Project` or `Namespace`. -* `source_id`: the ID of the row to retrieve based on `source_type`. For +- `source_id`: the ID of the row to retrieve based on `source_type`. For example, when `source_type` is `Project` then `source_id` will contain a project ID. @@ -92,10 +92,10 @@ AND source_id = 4 Instead such a table should be broken up into separate tables. For example, you may end up with 4 tables in this case: -* project_members -* group_members -* pending_project_members -* pending_group_members +- project_members +- group_members +- pending_project_members +- pending_group_members This makes querying data trivial. For example, to get the members of a group you'd run: diff --git a/doc/development/post_deployment_migrations.md b/doc/development/post_deployment_migrations.md index 5986efa9974..a41096aa3eb 100644 --- a/doc/development/post_deployment_migrations.md +++ b/doc/development/post_deployment_migrations.md @@ -70,6 +70,6 @@ version (which doesn't depend on the column anymore) has been deployed. Some other examples where these migrations are useful: -* Cleaning up data generated due to a bug in GitLab -* Removing tables -* Migrating jobs from one Sidekiq queue to another +- Cleaning up data generated due to a bug in GitLab +- Removing tables +- Migrating jobs from one Sidekiq queue to another diff --git a/doc/development/reusing_abstractions.md b/doc/development/reusing_abstractions.md index 83d7d42bd1f..01cedf734fb 100644 --- a/doc/development/reusing_abstractions.md +++ b/doc/development/reusing_abstractions.md @@ -149,11 +149,11 @@ typically in JSON. These are class methods defined by _GitLab itself_, including the following methods provided by Active Record: -* `find` -* `find_by_id` -* `delete_all` -* `destroy` -* `destroy_all` +- `find` +- `find_by_id` +- `delete_all` +- `destroy` +- `destroy_all` Any other methods such as `find_by(some_column: X)` are not included, and instead fall under the "Active Record" abstraction. @@ -163,10 +163,10 @@ instead fall under the "Active Record" abstraction. Instance methods defined on Active Record models by _GitLab itself_. Methods provided by Active Record are not included, except for the following methods: -* `save` -* `update` -* `destroy` -* `delete` +- `save` +- `update` +- `destroy` +- `delete` ### Active Record diff --git a/doc/development/rolling_out_changes_using_feature_flags.md b/doc/development/rolling_out_changes_using_feature_flags.md index b65fbc9d958..ef1aba95712 100644 --- a/doc/development/rolling_out_changes_using_feature_flags.md +++ b/doc/development/rolling_out_changes_using_feature_flags.md @@ -10,12 +10,12 @@ disable those changes, without having to revert an entire release. Starting with GitLab 11.4, developers are required to use feature flags for non-trivial changes. Such changes include: -* New features (e.g. a new merge request widget, epics, etc). -* Complex performance improvements that may require additional testing in +- New features (e.g. a new merge request widget, epics, etc). +- Complex performance improvements that may require additional testing in production, such as rewriting complex queries. -* Invasive changes to the user interface, such as a new navigation bar or the +- Invasive changes to the user interface, such as a new navigation bar or the removal of a sidebar. -* Adding support for importing projects from a third-party service. +- Adding support for importing projects from a third-party service. In all cases, those working on the changes can best decide if a feature flag is necessary. For example, changing the color of a button doesn't need a feature diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index f8993653aec..6012f1080ab 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -185,8 +185,8 @@ See this [section][vue-test]. `rake karma` runs the frontend-only (JavaScript) tests. It consists of two subtasks: -* `rake karma:fixtures` (re-)generates fixtures -* `rake karma:tests` actually executes the tests +- `rake karma:fixtures` (re-)generates fixtures +- `rake karma:tests` actually executes the tests As long as the fixtures don't change, `rake karma:tests` (or `yarn karma`) is sufficient (and saves you some time). @@ -243,14 +243,14 @@ supported by the PhantomJS test runner which is used for both Karma and RSpec tests. We polyfill some JavaScript objects for older browsers, but some features are still unavailable: -* Array.from -* Array.first -* Async functions -* Generators -* Array destructuring -* For..Of -* Symbol/Symbol.iterator -* Spread +- Array.from +- Array.first +- Async functions +- Generators +- Array destructuring +- For..Of +- Symbol/Symbol.iterator +- Spread Until these are polyfilled appropriately, they should not be used. Please update this list with additional unsupported features. diff --git a/doc/development/understanding_explain_plans.md b/doc/development/understanding_explain_plans.md index adf8795a5e3..01a0044f096 100644 --- a/doc/development/understanding_explain_plans.md +++ b/doc/development/understanding_explain_plans.md @@ -625,9 +625,9 @@ This is a bit of a difficult question to answer, because the definition of "bad" is relative to the problem you are trying to solve. However, some patterns are best avoided in most cases, such as: -* Sequential scans on large tables -* Filters that remove a lot of rows -* Performing a certain step (e.g. an index scan) that requires _a lot_ of +- Sequential scans on large tables +- Filters that remove a lot of rows +- Performing a certain step (e.g. an index scan) that requires _a lot_ of buffers (e.g. more than 512 MB for GitLab.com). As a general guideline, aim for a query that: @@ -650,8 +650,8 @@ different queries. The only _rule_ is that you _must always measure_ your query (preferably using a production-like database) using `EXPLAIN (ANALYZE, BUFFERS)` and related tools such as: -* <https://explain.depesz.com/> -* <http://tatiyants.com/postgres-query-plan-visualization/> +- <https://explain.depesz.com/> +- <http://tatiyants.com/postgres-query-plan-visualization/> GitLab employees can also use our chatops solution, available in Slack using the `/chatops` slash command. You can use chatops to get a query plan by running the diff --git a/doc/development/utilities.md b/doc/development/utilities.md index e5466ae8914..0e396baccff 100644 --- a/doc/development/utilities.md +++ b/doc/development/utilities.md @@ -4,7 +4,7 @@ We developed a number of utilities to ease development. ## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/merge_hash.rb) -* Deep merges an array of hashes: +- Deep merges an array of hashes: ``` ruby Gitlab::Utils::MergeHash.merge( @@ -31,7 +31,7 @@ We developed a number of utilities to ease development. ] ``` -* Extracts all keys and values from a hash into an array: +- Extracts all keys and values from a hash into an array: ``` ruby Gitlab::Utils::MergeHash.crush( @@ -47,14 +47,14 @@ We developed a number of utilities to ease development. ## [`Override`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/override.rb) -* This utility could help us check if a particular method would override +- This utility could help us check if a particular method would override another method or not. It has the same idea of Java's `@Override` annotation or Scala's `override` keyword. However we only do this check when `ENV['STATIC_VERIFICATION']` is set to avoid production runtime overhead. This is useful to check: - * If we have typos in overriding methods. - * If we renamed the overridden methods, making original overriding methods + - If we have typos in overriding methods. + - If we renamed the overridden methods, making original overriding methods overrides nothing. Here's a simple example: @@ -92,7 +92,7 @@ We developed a number of utilities to ease development. ## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/strong_memoize.rb) -* Memoize the value even if it is `nil` or `false`. +- Memoize the value even if it is `nil` or `false`. We often do `@value ||= compute`, however this doesn't work well if `compute` might eventually give `nil` and we don't want to compute again. @@ -126,7 +126,7 @@ We developed a number of utilities to ease development. end ``` -* Clear memoization +- Clear memoization ``` ruby class Find diff --git a/doc/development/verifying_database_capabilities.md b/doc/development/verifying_database_capabilities.md index ffdeff47d4a..661ab9cef1a 100644 --- a/doc/development/verifying_database_capabilities.md +++ b/doc/development/verifying_database_capabilities.md @@ -6,9 +6,9 @@ necessary to add database (version) specific behaviour. To facilitate this we have the following methods that you can use: -* `Gitlab::Database.postgresql?`: returns `true` if PostgreSQL is being used -* `Gitlab::Database.mysql?`: returns `true` if MySQL is being used -* `Gitlab::Database.version`: returns the PostgreSQL version number as a string +- `Gitlab::Database.postgresql?`: returns `true` if PostgreSQL is being used +- `Gitlab::Database.mysql?`: returns `true` if MySQL is being used +- `Gitlab::Database.version`: returns the PostgreSQL version number as a string in the format `X.Y.Z`. This method does not work for MySQL This allows you to write code such as: diff --git a/doc/install/installation.md b/doc/install/installation.md index c913474b638..5653c59f576 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -431,9 +431,9 @@ GitLab Shell is an SSH access and repository management software developed speci **Note:** GitLab Shell application startup time can be greatly reduced by disabling RubyGems. This can be done in several manners: -* Export `RUBYOPT=--disable-gems` environment variable for the processes -* Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommended for system-wide Ruby. -* Omnibus GitLab [replaces the *shebang* line of the `gitlab-shell/bin/*` scripts](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1707) +- Export `RUBYOPT=--disable-gems` environment variable for the processes. +- Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommended for system-wide Ruby. +- Omnibus GitLab [replaces the *shebang* line of the `gitlab-shell/bin/*` scripts](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1707). ### Install gitlab-workhorse diff --git a/doc/install/structure.md b/doc/install/structure.md index d58b0040eef..8fc6ab4ab2f 100644 --- a/doc/install/structure.md +++ b/doc/install/structure.md @@ -9,10 +9,10 @@ This is the directory structure you will end up with following the instructions | |-- gitlab-shell | |-- repositories -* `/home/git/.ssh` - contains openssh settings. Specifically the `authorized_keys` file managed by gitlab-shell. -* `/home/git/gitlab` - GitLab core software. -* `/home/git/gitlab-shell` - Core add-on component of GitLab. Maintains SSH cloning and other functionality. -* `/home/git/repositories` - bare repositories for all projects organized by namespace. This is where the git repositories which are pushed/pulled are maintained for all projects. **This area is critical data for projects. [Keep a backup](../raketasks/backup_restore.md)** +- `/home/git/.ssh` - contains openssh settings. Specifically the `authorized_keys` file managed by gitlab-shell. +- `/home/git/gitlab` - GitLab core software. +- `/home/git/gitlab-shell` - Core add-on component of GitLab. Maintains SSH cloning and other functionality. +- `/home/git/repositories` - bare repositories for all projects organized by namespace. This is where the git repositories which are pushed/pulled are maintained for all projects. **This area is critical data for projects. [Keep a backup](../raketasks/backup_restore.md).** *Note: the default locations for repositories can be configured in `config/gitlab.yml` of GitLab and `config.yml` of gitlab-shell.* diff --git a/doc/integration/gmail_action_buttons_for_gitlab.md b/doc/integration/gmail_action_buttons_for_gitlab.md index c19320471e3..cc5d444c069 100644 --- a/doc/integration/gmail_action_buttons_for_gitlab.md +++ b/doc/integration/gmail_action_buttons_for_gitlab.md @@ -14,9 +14,9 @@ To get this functioning, you need to be registered with Google. Pay close attention to: -* Email account used by GitLab to send notification emails needs to have "Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least". -* "A very very low rate of spam complaints from users." -* Emails must be authenticated via DKIM or SPF -* Before sending the final form("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there. +- Email account used by GitLab to send notification emails needs to have "Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least". +- "A very very low rate of spam complaints from users." +- Emails must be authenticated via DKIM or SPF. +- Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there. You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/1517). diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md index 4e1d5ba9b35..f5f1f9486c2 100644 --- a/doc/integration/omniauth.md +++ b/doc/integration/omniauth.md @@ -66,7 +66,7 @@ that are in common for all providers that we need to consider. To change these settings: -* **For omnibus package** +- **For omnibus package** Open the configuration file: @@ -89,7 +89,7 @@ To change these settings: gitlab_rails['omniauth_block_auto_created_users'] = true ``` -* **For installations from source** +- **For installations from source** Open the configuration file: diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md index 03ba2ae8817..1b93cdb83ac 100644 --- a/doc/policy/maintenance.md +++ b/doc/policy/maintenance.md @@ -15,9 +15,9 @@ GitLab follows the [Semantic Versioning](http://semver.org/) for its releases: For example, for GitLab version 10.5.7: -* `10` represents major version -* `5` represents minor version -* `7` represents patch number +- `10` represents major version +- `5` represents minor version +- `7` represents patch number ## Patch releases @@ -55,13 +55,13 @@ cases you need to consider. It is considered safe to jump between patch versions and minor versions within one major version. For example, it is safe to: -* Upgrade the patch version: - * `8.9.0` -> `8.9.7` - * `8.9.0` -> `8.9.1` - * `8.9.2` -> `8.9.6` -* Upgrade the minor version: - * `8.9.4` -> `8.12.3` - * `9.2.3` -> `9.5.5` +- Upgrade the patch version: + - `8.9.0` -> `8.9.7` + - `8.9.0` -> `8.9.1` + - `8.9.2` -> `8.9.6` +- Upgrade the minor version: + - `8.9.4` -> `8.12.3` + - `9.2.3` -> `9.5.5` Upgrading the major version requires more attention. We cannot guarantee that upgrading between major versions will be seamless. As previously mentioned, major versions are reserved for backwards incompatible changes. diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md index 94ba5d1375d..d61a205d954 100644 --- a/doc/security/crime_vulnerability.md +++ b/doc/security/crime_vulnerability.md @@ -17,8 +17,8 @@ GitLab supports both gzip and [SPDY][ngx-spdy] and mitigates the CRIME vulnerability by deactivating gzip when HTTPS is enabled. You can see the sources of the files in question: -* [Source installation NGINX file][source-nginx] -* [Omnibus installation NGINX file][omnibus-nginx] +- [Source installation NGINX file][source-nginx] +- [Omnibus installation NGINX file][omnibus-nginx] Although SPDY is enabled in Omnibus installations, CRIME relies on compression (the 'C') and the default compression level in NGINX's SPDY module is 0 @@ -52,9 +52,9 @@ vulnerability. ### References -* Nginx ["Module ngx_http_spdy_module"][ngx-spdy] -* Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus] -* Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia +- Nginx ["Module ngx_http_spdy_module"][ngx-spdy] +- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus] +- Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia [source-nginx]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab-ssl [omnibus-nginx]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 008791d5ef6..839481a0ed6 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -539,9 +539,9 @@ a helm pre-upgrade hook. For example, in a Rails application: -* `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production +- `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production bin/setup` -* `DB_MIGRATE` can be set to `cd /app && RAILS_ENV=production bin/update` +- `DB_MIGRATE` can be set to `cd /app && RAILS_ENV=production bin/update` NOTE: **Note:** The `/app` path is the directory of your project inside the docker image diff --git a/doc/university/high-availability/aws/README.md b/doc/university/high-availability/aws/README.md index 2aabbf3be86..77a1892b656 100644 --- a/doc/university/high-availability/aws/README.md +++ b/doc/university/high-availability/aws/README.md @@ -66,10 +66,10 @@ RDS instances as well. The subnets are listed with their name, AZ and CIDR block: -* gitlab-public-10.0.0.0 - us-west-2a - 10.0.0.0 -* gitlab-private-10.0.1.0 - us-west-2a - 10.0.1.0 -* gitlab-public-10.0.2.0 - us-west-2b - 10.0.2.0 -* gitlab-private-10.0.3.0 - us-west-2b - 10.0.3.0 +- gitlab-public-10.0.0.0 - us-west-2a - 10.0.0.0 +- gitlab-private-10.0.1.0 - us-west-2a - 10.0.1.0 +- gitlab-public-10.0.2.0 - us-west-2b - 10.0.2.0 +- gitlab-private-10.0.3.0 - us-west-2b - 10.0.3.0 ### Route Table @@ -395,5 +395,5 @@ some redundancy options but it might also imply Geographic replication. There is a lot of ground yet to cover so have a read through these other resources and feel free to open an issue to request additional material. -* [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High%20Availability) -* [GitLab Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html) +- [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High%20Availability) +- [GitLab Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html) diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md index 701533358c8..637e4e3c791 100644 --- a/doc/university/training/end-user/README.md +++ b/doc/university/training/end-user/README.md @@ -242,10 +242,11 @@ git push origin squash_some_bugs --- ### Merge Conflicts -* Happen often -* Learning to fix conflicts is hard -* Practice makes perfect -* Force push after fixing conflicts. Be careful! + +- Happen often +- Learning to fix conflicts is hard +- Practice makes perfect +- Force push after fixing conflicts. Be careful! --- @@ -306,10 +307,10 @@ Create a merge request on the GitLab web UI. You'll see a conflict warning. ### Notes -* When to use `git merge` and when to use `git rebase` -* Rebase when updating your branch with master -* Merge when bringing changes from feature to master -* Reference: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/ +- When to use `git merge` and when to use `git rebase` +- Rebase when updating your branch with master +- Merge when bringing changes from feature to master +- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/> --- diff --git a/doc/university/training/topics/getting_started.md b/doc/university/training/topics/getting_started.md index 66cb08feacb..d76ff57bfa3 100644 --- a/doc/university/training/topics/getting_started.md +++ b/doc/university/training/topics/getting_started.md @@ -8,12 +8,12 @@ comments: false ## Instantiating Repositories -* Create a new repository by instantiating it through +- Create a new repository by instantiating it through: ```bash git init ``` -* Copy an existing project by cloning the repository through +- Copy an existing project by cloning the repository through: ```bash git clone <url> @@ -23,9 +23,9 @@ comments: false ## Central Repos -* To instantiate a central repository a `--bare` flag is required. -* Bare repositories don't allow file editing or committing changes. -* Create a bare repo with +- To instantiate a central repository a `--bare` flag is required. +- Bare repositories don't allow file editing or committing changes. +- Create a bare repo with: ```bash git init --bare project-name.git @@ -97,5 +97,5 @@ git log ## Note -* git fetch vs pull -* Pull is git fetch + git merge +- git fetch vs pull +- Pull is git fetch + git merge diff --git a/doc/university/training/topics/git_add.md b/doc/university/training/topics/git_add.md index b1483e725fe..e02a7deab91 100644 --- a/doc/university/training/topics/git_add.md +++ b/doc/university/training/topics/git_add.md @@ -10,13 +10,13 @@ comments: false Adds content to the index or staging area. -* Adds a list of file +- Adds a list of file: ```bash git add <files> ``` -* Adds all files including deleted ones +- Adds all files including deleted ones: ```bash git add -A @@ -26,19 +26,19 @@ Adds content to the index or staging area. ## Git add continued -* Add all text files in current dir +- Add all text files in current dir: ```bash git add *.txt ``` -* Add all text file in the project +- Add all text file in the project: ```bash git add "*.txt*" ``` -* Adds all files in directory +- Adds all files in directory: ```bash git add views/layouts/ diff --git a/doc/university/training/topics/git_log.md b/doc/university/training/topics/git_log.md index 6ba6f9eb69d..127fdf4d44a 100644 --- a/doc/university/training/topics/git_log.md +++ b/doc/university/training/topics/git_log.md @@ -8,19 +8,19 @@ comments: false Git log lists commit history. It allows searching and filtering. -* Initiate log +- Initiate log: ``` git log ``` -* Retrieve set number of records: +- Retrieve set number of records: ``` git log -n 2 ``` -* Search commits by author. Allows user name or a regular expression. +- Search commits by author. Allows user name or a regular expression. ``` git log --author="user_name" @@ -28,13 +28,13 @@ Git log lists commit history. It allows searching and filtering. ---------- -* Search by comment message. +- Search by comment message: ``` git log --grep="<pattern>" ``` -* Search by date +- Search by date: ``` git log --since=1.month.ago --until=3.weeks.ago diff --git a/doc/university/training/topics/merge_conflicts.md b/doc/university/training/topics/merge_conflicts.md index 071baddf508..a7d42904229 100644 --- a/doc/university/training/topics/merge_conflicts.md +++ b/doc/university/training/topics/merge_conflicts.md @@ -68,7 +68,8 @@ git push origin conflicts_branch -f ---------- ## Note -* When to use 'git merge' and when to use 'git rebase' -* Rebase when updating your branch with master -* Merge when bringing changes from feature to master -* Reference: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/ + +- When to use 'git merge' and when to use 'git rebase' +- Rebase when updating your branch with master +- Merge when bringing changes from feature to master +- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/> diff --git a/doc/university/training/topics/rollback_commits.md b/doc/university/training/topics/rollback_commits.md index 44304634f36..ca3a64e4347 100644 --- a/doc/university/training/topics/rollback_commits.md +++ b/doc/university/training/topics/rollback_commits.md @@ -8,13 +8,13 @@ comments: false ## Undo Commits -* Undo last commit putting everything back into the staging area. +- Undo last commit putting everything back into the staging area: ``` git reset --soft HEAD^ ``` -* Add files and change message with: +- Add files and change message with: ``` git commit --amend -m "New Message" @@ -22,13 +22,13 @@ comments: false ---------- -* Undo last and remove changes +- Undo last and remove changes: ``` git reset --hard HEAD^ ``` -* Same as last one but for two commits back +- Same as last one but for two commits back: ``` git reset --hard HEAD^^ @@ -73,9 +73,9 @@ git push origin master ## Note -* git revert vs git reset -* Reset removes the commit while revert removes the changes but leaves the commit -* Revert is safer considering we can revert a revert +- git revert vs git reset +- Reset removes the commit while revert removes the changes but leaves the commit +- Revert is safer considering we can revert a revert ``` # Changed file diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md index 42eedea14e5..f1c91fb1b37 100644 --- a/doc/university/training/topics/stash.md +++ b/doc/university/training/topics/stash.md @@ -9,7 +9,7 @@ comments: false We use git stash to store our changes when they are not ready to be committed and we need to change to a different branch. -* Stash +- Stash: ``` git stash save @@ -19,7 +19,7 @@ and we need to change to a different branch. git stash save "this is a message to display on the list" ``` -* Apply stash to keep working on it +- Apply stash to keep working on it: ``` git stash apply @@ -29,7 +29,7 @@ and we need to change to a different branch. ---------- -* Every time we save a stash it gets stacked so by using list we can see all our +- Every time we save a stash it gets stacked so by using list we can see all our stashes. ``` @@ -38,7 +38,7 @@ stashes. git stash list --stat ``` -* To clean our stack we need to manually remove them. +- To clean our stack we need to manually remove them: ``` # drop top stash @@ -51,15 +51,14 @@ stashes. ---------- -* Apply and drop on one command +- Apply and drop on one command: ``` git stash pop ``` -* If we meet conflicts we need to either reset or commit our changes. - -* Conflicts through `pop` will not drop a stash afterwards. +- If we meet conflicts we need to either reset or commit our changes. +- Conflicts through `pop` will not drop a stash afterwards. ---------- diff --git a/doc/university/training/topics/subtree.md b/doc/university/training/topics/subtree.md index b5a892dc17b..ba7c3394938 100644 --- a/doc/university/training/topics/subtree.md +++ b/doc/university/training/topics/subtree.md @@ -4,20 +4,20 @@ comments: false # Subtree -* Used when there are nested repositories. -* Not recommended when the amount of dependencies is too large -* For these cases we need a dependency control system -* Command are painfully long so aliases are necessary +- Used when there are nested repositories. +- Not recommended when the amount of dependencies is too large. +- For these cases we need a dependency control system. +- Command are painfully long so aliases are necessary. ---------- ## Subtree Aliases -* Add: git subtree add --prefix <target-folder> <url> <branch> --squash -* Pull: git subtree add --prefix <target-folder> <url> <branch> --squash -* Push: git subtree add --prefix <target-folder> <url> <branch> -* Ex: git config alias.sbp 'subtree pull --prefix st / - git@gitlab.com:balameb/subtree-nested-example.git master --squash' +- Add: git subtree add --prefix <target-folder> <url> <branch> --squash. +- Pull: git subtree add --prefix <target-folder> <url> <branch> --squash. +- Push: git subtree add --prefix <target-folder> <url> <branch>. +- Ex: git config alias.sbp 'subtree pull --prefix st / + git@gitlab.com:balameb/subtree-nested-example.git master --squash'. ---------- diff --git a/doc/university/training/topics/unstage.md b/doc/university/training/topics/unstage.md index ee7913637b9..da36a3218e5 100644 --- a/doc/university/training/topics/unstage.md +++ b/doc/university/training/topics/unstage.md @@ -8,13 +8,13 @@ comments: false ## Unstage -* To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch. +- To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch. ```bash git reset HEAD <file> ``` -* This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use: +- This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use: ```bash git checkout -- <file> @@ -22,14 +22,14 @@ comments: false ---------- -* To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag. +- To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag: ``` git rm '*.txt' git rm -r <dirname> ``` -* If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`. +- If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`: ``` git rm <filename> --cache diff --git a/doc/update/6.9-to-7.0.md b/doc/update/6.9-to-7.0.md index 781c90e4198..7f3abf74675 100644 --- a/doc/update/6.9-to-7.0.md +++ b/doc/update/6.9-to-7.0.md @@ -110,8 +110,8 @@ There are new configuration options available for gitlab.yml. View them with the git diff origin/6-9-stable:config/gitlab.yml.example origin/7-0-stable:config/gitlab.yml.example ``` -* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting. ### 7. Start application diff --git a/doc/update/6.x-or-7.x-to-7.14.md b/doc/update/6.x-or-7.x-to-7.14.md index 6fcec5b7974..c20a72ce162 100644 --- a/doc/update/6.x-or-7.x-to-7.14.md +++ b/doc/update/6.x-or-7.x-to-7.14.md @@ -178,16 +178,16 @@ TIP: to see what changed in `gitlab.yml.example` in this release use next comman git diff 6-0-stable:config/gitlab.yml.example 7-14-stable:config/gitlab.yml.example ``` -* Make `/home/git/gitlab/config/gitlab.yml` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/config/gitlab.yml.example but with your settings. -* Make `/home/git/gitlab/config/unicorn.rb` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/config/unicorn.rb.example but with your settings. -* Make `/home/git/gitlab-shell/config.yml` the same as https://gitlab.com/gitlab-org/gitlab-shell/blob/v2.6.5/config.yml.example but with your settings. -* Copy rack attack middleware config +- Make `/home/git/gitlab/config/gitlab.yml` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/config/gitlab.yml.example but with your settings. +- Make `/home/git/gitlab/config/unicorn.rb` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/config/unicorn.rb.example but with your settings. +- Make `/home/git/gitlab-shell/config.yml` the same as https://gitlab.com/gitlab-org/gitlab-shell/blob/v2.6.5/config.yml.example but with your settings. +- Copy rack attack middleware config. ```bash sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb ``` -* Set up logrotate +- Set up logrotate ```bash sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab @@ -195,9 +195,9 @@ sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab ### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/lib/support/nginx/gitlab but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/lib/support/nginx/gitlab-ssl but with your settings. -* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/lib/support/nginx/gitlab but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-14-stable/lib/support/nginx/gitlab-ssl but with your settings. +- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. ### Check the version of /usr/local/bin/git diff --git a/doc/update/7.1-to-7.2.md b/doc/update/7.1-to-7.2.md index 07f92ac3af6..b69bd391241 100644 --- a/doc/update/7.1-to-7.2.md +++ b/doc/update/7.1-to-7.2.md @@ -94,8 +94,8 @@ There are new configuration options available for `gitlab.yml`. View them with t git diff 7-1-stable:config/gitlab.yml.example 7-2-stable:config/gitlab.yml.example ``` -* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting. Update rack attack middleware config diff --git a/doc/update/7.2-to-7.3.md b/doc/update/7.2-to-7.3.md index a16f9de54e4..b69a9927f37 100644 --- a/doc/update/7.2-to-7.3.md +++ b/doc/update/7.2-to-7.3.md @@ -108,8 +108,8 @@ git diff origin/7-2-stable:config/gitlab.yml.example origin/7-3-stable:config/gi sudo -u git -H sed -i 's/:backlog => 64/:backlog => 1024/' config/unicorn.rb ``` -* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab-ssl but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab-ssl but with your setting. ### 7. Start application diff --git a/doc/update/7.3-to-7.4.md b/doc/update/7.3-to-7.4.md index 734c655f1d1..3786095bb8b 100644 --- a/doc/update/7.3-to-7.4.md +++ b/doc/update/7.3-to-7.4.md @@ -75,11 +75,11 @@ sudo -u git -H editor config/unicorn.rb #### Change Nginx HTTPS settings -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-4-stable/lib/support/nginx/gitlab-ssl but with your setting +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-4-stable/lib/support/nginx/gitlab-ssl but with your setting. #### MySQL Databases: Update database.yml config file -* Add `collation: utf8_general_ci` to `config/database.yml` as seen in [config/database.yml.mysql][mysql]: +- Add `collation: utf8_general_ci` to `config/database.yml` as seen in [config/database.yml.mysql][mysql]: ``` sudo -u git -H editor config/database.yml @@ -136,7 +136,7 @@ SET foreign_key_checks = 1; # Find MySQL users mysql> SELECT user FROM mysql.user WHERE user LIKE '%git%'; -# If git user exists and gitlab user does not exist +# If git user exists and gitlab user does not exist # you are done with the database cleanup tasks mysql> \q diff --git a/doc/update/7.4-to-7.5.md b/doc/update/7.4-to-7.5.md index 7a3a49ff948..d93d32d1b60 100644 --- a/doc/update/7.4-to-7.5.md +++ b/doc/update/7.4-to-7.5.md @@ -77,8 +77,8 @@ git diff origin/7-4-stable:config/gitlab.yml.example origin/7-5-stable:config/gi #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting. ### 6. Start application diff --git a/doc/update/7.5-to-7.6.md b/doc/update/7.5-to-7.6.md index 0d45a9528b9..0e87918c8c0 100644 --- a/doc/update/7.5-to-7.6.md +++ b/doc/update/7.5-to-7.6.md @@ -79,8 +79,8 @@ git diff origin/7-5-stable:config/gitlab.yml.example origin/7-6-stable:config/gi #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting. #### Set up time zone (optional) diff --git a/doc/update/7.6-to-7.7.md b/doc/update/7.6-to-7.7.md index 5e0b2ca7bcd..c24b5647f21 100644 --- a/doc/update/7.6-to-7.7.md +++ b/doc/update/7.6-to-7.7.md @@ -79,8 +79,8 @@ git diff origin/7-6-stable:config/gitlab.yml.example origin/7-7-stable:config/gi #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting. #### Set up time zone (optional) diff --git a/doc/update/7.7-to-7.8.md b/doc/update/7.7-to-7.8.md index f5b1ebf0a9c..61bd5fb1298 100644 --- a/doc/update/7.7-to-7.8.md +++ b/doc/update/7.7-to-7.8.md @@ -79,9 +79,9 @@ git diff origin/7-7-stable:config/gitlab.yml.example origin/7-8-stable:config/gi #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. -* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. +- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. #### Set up time zone (optional) diff --git a/doc/update/7.8-to-7.9.md b/doc/update/7.8-to-7.9.md index 0db7698936b..c13dd5b60e6 100644 --- a/doc/update/7.8-to-7.9.md +++ b/doc/update/7.8-to-7.9.md @@ -81,9 +81,9 @@ git diff origin/7-8-stable:config/gitlab.yml.example origin/7-9-stable:config/gi #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. -* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. +- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. #### Set up time zone (optional) diff --git a/doc/update/7.9-to-7.10.md b/doc/update/7.9-to-7.10.md index 782fb0736e6..4dece93652e 100644 --- a/doc/update/7.9-to-7.10.md +++ b/doc/update/7.9-to-7.10.md @@ -77,9 +77,9 @@ git diff origin/7-9-stable:config/gitlab.yml.example origin/7-10-stable:config/g #### Change Nginx settings -* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. -* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. -* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. +- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings. +- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings. +- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section. #### Set up time zone (optional) diff --git a/doc/update/upgrading_postgresql_using_slony.md b/doc/update/upgrading_postgresql_using_slony.md index f009906256e..51178809b4c 100644 --- a/doc/update/upgrading_postgresql_using_slony.md +++ b/doc/update/upgrading_postgresql_using_slony.md @@ -176,10 +176,10 @@ if ($ENV{"SLONYSET"}) { In this configuration file you should replace a few placeholders before you can use it. The following placeholders should be replaced: -* `OLD_HOST`: the address of the old database server. -* `NEW_HOST`: the address of the new database server. -* `SLONY_PASSWORD`: the password of the Slony user created earlier. -* `TABLES`: the tables to replicate. +- `OLD_HOST`: the address of the old database server. +- `NEW_HOST`: the address of the new database server. +- `SLONY_PASSWORD`: the password of the Slony user created earlier. +- `TABLES`: the tables to replicate. The list of tables to replicate can be generated by running the following command on your old PostgreSQL database: diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index bd0155dc712..e165a120162 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -12,9 +12,9 @@ If enabled, version check will inform you if a new version is available and the importance of it through a status. This is shown on the help page (i.e. `/help`) for all signed in users, and on the admin pages. The statuses are: -* Green: You are running the latest version of GitLab. -* Orange: An updated version of GitLab is available. -* Red: The version of GitLab you are running is vulnerable. You should install +- Green: You are running the latest version of GitLab. +- Orange: An updated version of GitLab is available. +- Red: The version of GitLab you are running is vulnerable. You should install the latest version with security fixes as soon as possible.  diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index e14e716a5eb..68a0f1a5837 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -281,12 +281,14 @@ of proposed changes can be found at GitLab.com adjusts the memory limits for the [unicorn-worker-killer][unicorn-worker-killer] gem. Base default: -* `memory_limit_min` = 750MiB -* `memory_limit_max` = 1024MiB + +- `memory_limit_min` = 750MiB +- `memory_limit_max` = 1024MiB Web front-ends: -* `memory_limit_min` = 1024MiB -* `memory_limit_max` = 1280MiB + +- `memory_limit_min` = 1024MiB +- `memory_limit_max` = 1280MiB ## GitLab.com at scale diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md index 943b0c693c0..4d56b33f684 100644 --- a/doc/user/group/subgroups/index.md +++ b/doc/user/group/subgroups/index.md @@ -21,8 +21,8 @@ Nested groups are only supported when you use PostgreSQL. Supporting nested groups on MySQL in an efficient way is not possible due to MySQL's limitations. See the following links for more information: -* <https://gitlab.com/gitlab-org/gitlab-ce/issues/30472> -* <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885> +- <https://gitlab.com/gitlab-org/gitlab-ce/issues/30472> +- <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885> ## Overview diff --git a/doc/user/instance_statistics/user_cohorts.md b/doc/user/instance_statistics/user_cohorts.md index 70d5912dc4e..f52f24ef5f7 100644 --- a/doc/user/instance_statistics/user_cohorts.md +++ b/doc/user/instance_statistics/user_cohorts.md @@ -23,5 +23,5 @@ the month, but who have never actually had any activity in the instance. How do we measure the activity of users? GitLab considers a user active if: -* the user signs in -* the user has Git activity (whether push or pull). +- The user signs in. +- The user has Git activity (whether push or pull). diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md index 76f7e869ff7..83bc79925e1 100644 --- a/doc/user/profile/account/two_factor_authentication.md +++ b/doc/user/profile/account/two_factor_authentication.md @@ -43,8 +43,8 @@ or a U2F device. 1. Install a compatible application. We recommend [Google Authenticator] \(proprietary\) or [FreeOTP] \(open source\). 1. In the application, add a new entry in one of two ways: - * Scan the code with your phone's camera to add the entry automatically. - * Enter the details provided to add the entry manually. + - Scan the code with your phone's camera to add the entry automatically. + - Enter the details provided to add the entry manually. **In GitLab:** @@ -106,7 +106,7 @@ Enter the pin from your one time password authenticator's application or a recov ### Log in via U2F device -1. Click **Login via U2F Device** +1. Click **Login via U2F Device**. 1. A light will start blinking on your device. Activate it by pressing its button. You will see a message indicating that your device responded to the authentication request. @@ -135,9 +135,9 @@ authenticate with Git over HTTPS on the command line or when using To disable two-factor authentication on your account (for example, if you have lost your code generation device) you can: -* [Use a saved recovery code](#use-a-saved-recovery-code) -* [Generate new recovery codes using SSH](#generate-new-recovery-codes-using-ssh) -* [Ask a GitLab administrator to disable two-factor authentication on your account](#ask-a-gitlab-administrator-to-disable-two-factor-authentication-on-your-account) +- [Use a saved recovery code](#use-a-saved-recovery-code). +- [Generate new recovery codes using SSH](#generate-new-recovery-codes-using-ssh). +- [Ask a GitLab administrator to disable two-factor authentication on your account](#ask-a-gitlab-administrator-to-disable-two-factor-authentication-on-your-account). ### Use a saved recovery code diff --git a/doc/user/project/container_registry.md b/doc/user/project/container_registry.md index cac64fc0cb6..eb9e1cd85cd 100644 --- a/doc/user/project/container_registry.md +++ b/doc/user/project/container_registry.md @@ -283,9 +283,9 @@ In the example above, we see the following trace on the mitmproxy window: The above image shows: -* The initial PUT requests went through fine with a 201 status code. -* The 201 redirected the client to the S3 bucket. -* The HEAD request to the AWS bucket reported a 403 Unauthorized. +- The initial PUT requests went through fine with a 201 status code. +- The 201 redirected the client to the S3 bucket. +- The HEAD request to the AWS bucket reported a 403 Unauthorized. What does this mean? This strongly suggests that the S3 user does not have the right [permissions to perform a HEAD request](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html). diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index 42da2210fab..b36373b4830 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -18,16 +18,16 @@ GitHub without the constraints of a Sidekiq worker. The following aspects of a project are imported: - * Repository description (GitLab.com & 7.7+) - * Git repository data (GitLab.com & 7.7+) - * Issues (GitLab.com & 7.7+) - * Pull requests (GitLab.com & 8.4+) - * Wiki pages (GitLab.com & 8.4+) - * Milestones (GitLab.com & 8.7+) - * Labels (GitLab.com & 8.7+) - * Release note descriptions (GitLab.com & 8.12+) - * Pull request review comments (GitLab.com & 10.2+) - * Regular issue and pull request comments +- Repository description (GitLab.com & 7.7+) +- Git repository data (GitLab.com & 7.7+) +- Issues (GitLab.com & 7.7+) +- Pull requests (GitLab.com & 8.4+) +- Wiki pages (GitLab.com & 8.4+) +- Milestones (GitLab.com & 8.7+) +- Labels (GitLab.com & 8.7+) +- Release note descriptions (GitLab.com & 8.12+) +- Pull request review comments (GitLab.com & 10.2+) +- Regular issue and pull request comments References to pull requests and issues are preserved (GitLab.com & 8.7+), and each imported repository maintains visibility level unless that [visibility @@ -132,8 +132,8 @@ Admin access to the GitLab server is required. For large projects it may take a while to import all data. To reduce the time necessary, you can increase the number of Sidekiq workers that process the following queues: -* `github_importer` -* `github_importer_advance_stage` +- `github_importer` +- `github_importer_advance_stage` For an optimal experience, it's recommended having at least 4 Sidekiq processes (each running a number of threads equal to the number of CPU cores) that *only* process these queues. It's also recommended that these processes run on separate diff --git a/doc/user/project/integrations/emails_on_push.md b/doc/user/project/integrations/emails_on_push.md index df320de7e16..61359dcaa90 100644 --- a/doc/user/project/integrations/emails_on_push.md +++ b/doc/user/project/integrations/emails_on_push.md @@ -10,10 +10,10 @@ In the _Recipients_ area, provide a list of emails separated by spaces or newlin The following options are available: -+ **Push events** - Email will be triggered when a push event is received -+ **Tag push events** - Email will be triggered when a tag is created and pushed -+ **Send from committer** - Send notifications from the committer's email address if the domain is part of the domain GitLab is running on (e.g. `user@gitlab.com`). -+ **Disable code diffs** - Don't include possibly sensitive code diffs in notification body. +- **Push events** - Email will be triggered when a push event is received. +- **Tag push events** - Email will be triggered when a tag is created and pushed. +- **Send from committer** - Send notifications from the committer's email address if the domain is part of the domain GitLab is running on (e.g. `user@gitlab.com`). +- **Disable code diffs** - Don't include possibly sensitive code diffs in notification body. | Settings | Notification | | --- | --- | diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md index bc4bba40e59..754711f5919 100644 --- a/doc/user/project/integrations/jira.md +++ b/doc/user/project/integrations/jira.md @@ -31,7 +31,7 @@ directly from GitLab, as covered in the article Each GitLab project can be configured to connect to an entire Jira instance. That means one GitLab project can interact with _all_ Jira projects in that instance, once -configured. Therefore, you will not have to explicitly associate +configured. Therefore, you will not have to explicitly associate a GitLab project with any single Jira project. If you have one Jira instance, you can pre-fill the settings page with a default @@ -46,10 +46,12 @@ project in Jira and then enter the correct values in GitLab. ### Configuring Jira When connecting to **JIRA Server**, which supports basic authentication, a **username and password** are required. Check the link below and proceed to the next step: -* [Setting up an user in JIRA server](jira_server_configuration.md) + +- [Setting up an user in JIRA server](jira_server_configuration.md) When connecting to **JIRA Cloud**, which supports authentication via API token, an **email and API token**, are required. Check the link below and proceed to the next step: -* [Setting up an user in JIRA cloud](jira_cloud_configuration.md) + +- [Setting up an user in JIRA cloud](jira_cloud_configuration.md) ### Configuring GitLab @@ -114,11 +116,11 @@ USER mentioned this issue in RESOURCE_NAME of [PROJECT_NAME|LINK_TO_COMMENT]: ENTITY_TITLE ``` -* `USER` A user that mentioned the issue. This is the link to the user profile in GitLab. -* `LINK_TO_THE_COMMENT` Link to the origin of mention with a name of the entity where Jira issue was mentioned. -* `RESOURCE_NAME` Kind of resource which referenced the issue. Can be a commit or merge request. -* `PROJECT_NAME` GitLab project name. -* `ENTITY_TITLE` Merge request title or commit message first line. +- `USER` A user that mentioned the issue. This is the link to the user profile in GitLab. +- `LINK_TO_THE_COMMENT` Link to the origin of mention with a name of the entity where Jira issue was mentioned. +- `RESOURCE_NAME` Kind of resource which referenced the issue. Can be a commit or merge request. +- `PROJECT_NAME` GitLab project name. +- `ENTITY_TITLE` Merge request title or commit message first line.  @@ -190,11 +192,11 @@ Make sure that the Jira issue is not already marked as resolved; that is, the Jira issue resolution field is not set. (It should not be struck through in Jira lists.) -### CAPTCHA +### CAPTCHA -CAPTCHA may be triggered after several consecutive failed login attempts +CAPTCHA may be triggered after several consecutive failed login attempts which may lead to a `401 unauthorized` error when testing your Jira integration. -If CAPTCHA has been triggered, you will not be able to use Jira's REST API to +If CAPTCHA has been triggered, you will not be able to use Jira's REST API to authenticate with the Jira site. You will need to log in to your Jira instance and complete the CAPTCHA. diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md index 5de8e66e7eb..d6ee678443f 100644 --- a/doc/user/project/integrations/prometheus.md +++ b/doc/user/project/integrations/prometheus.md @@ -9,8 +9,9 @@ within the GitLab interface.  There are two ways to set up Prometheus integration, depending on where your apps are running: -* For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes) -* For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus). + +- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes). +- For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus). Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments). @@ -23,8 +24,8 @@ GitLab can seamlessly deploy and manage Prometheus on a [connected Kubernetes cl #### Requirements -* A [connected Kubernetes cluster](../clusters/index.md) -* Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications) +- A [connected Kubernetes cluster](../clusters/index.md) +- Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications) #### Getting started @@ -42,9 +43,9 @@ Prometheus is deployed into the `gitlab-managed-apps` namespace, using the [offi The Prometheus server will [automatically detect and monitor](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Ckubernetes_sd_config%3E) nodes, pods, and endpoints. To configure a resource to be monitored by Prometheus, simply set the following [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/): -* `prometheus.io/scrape` to `true` to enable monitoring of the resource. -* `prometheus.io/port` to define the port of the metrics endpoint. -* `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`. +- `prometheus.io/scrape` to `true` to enable monitoring of the resource. +- `prometheus.io/port` to define the port of the metrics endpoint. +- `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`. CPU and Memory consumption is monitored, but requires [naming conventions](prometheus_library/kubernetes.html#specifying-the-environment) in order to determine the environment. If you are using [Auto DevOps](../../../topics/autodevops/), this is handled automatically. diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md index 40ac855c74f..d5f77d622be 100644 --- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md +++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md @@ -21,18 +21,20 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus. For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation: -* NGINX Ingress should be version 0.9.0 or above, with metrics enabled -* NGINX Ingress should be annotated for Prometheus monitoring -* Prometheus should be configured to monitor annotated pods + +- NGINX Ingress should be version 0.9.0 or above, with metrics enabled +- NGINX Ingress should be annotated for Prometheus monitoring +- Prometheus should be configured to monitor annotated pods ### About managed NGINX Ingress deployments NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's IP](../../clusters/index.md#getting-the-external-ip-address). NGINX is configured for Prometheus monitoring, by setting: -* `enable-vts-status: "true"`, to export Prometheus metrics -* `prometheus.io/scrape: "true"`, to enable automatic discovery -* `prometheus.io/port: "10254"`, to specify the metrics port + +- `enable-vts-status: "true"`, to export Prometheus metrics +- `prometheus.io/scrape: "true"`, to enable automatic discovery +- `prometheus.io/port: "10254"`, to specify the metrics port When used in conjunction with the GitLab deployed Prometheus service, response metrics will be automatically collected. @@ -42,8 +44,8 @@ Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added: -* `prometheus.io/scrape: "true"` -* `prometheus.io/port: "10254"` +- `prometheus.io/scrape: "true"` +- `prometheus.io/port: "10254"` Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard). diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index a19989afb91..f479f9e4ef6 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -328,8 +328,8 @@ troubleshooting steps. This can occur for one of two reasons: -* Sidekiq doesn't pick up the changes fast enough -* Because of the bug described in [#41545](https://gitlab.com/gitlab-org/gitlab-ce/issues/41545) +- Sidekiq doesn't pick up the changes fast enough +- Because of the bug described in [#41545](https://gitlab.com/gitlab-org/gitlab-ce/issues/41545) #### Sidekiq diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md index 2ec423dcf70..1b57331dbe7 100644 --- a/doc/user/project/merge_requests/squash_and_merge.md +++ b/doc/user/project/merge_requests/squash_and_merge.md @@ -18,7 +18,7 @@ Into a single commit on merge: ![A squashed commit followed by a merge commit][squashed-commit] -The squashed commit's commit message is the merge request title. And note that +The squashed commit's commit message is the merge request title. And note that the squashed commit is still followed by a merge commit, as the merge method for this example repository uses a merge commit. Squashing also works with the fast-forward merge strategy, see @@ -30,7 +30,7 @@ details. When working on a feature branch, you sometimes want to commit your current progress, but don't really care about the commit messages. Those 'work in progress commits' don't necessarily contain important information and as such -you'd rather not include them in your target branch. +you'd rather not include them in your target branch. With squash and merge, when the merge request is ready to be merged, all you have to do is enable squashing before you press merge to join @@ -56,9 +56,9 @@ This can then be overridden at the time of accepting the merge request: The squashed commit has the following metadata: -* Message: the title of the merge request. -* Author: the author of the merge request. -* Committer: the user who initiated the squash. +- Message: the title of the merge request. +- Author: the author of the merge request. +- Committer: the user who initiated the squash. ## Squash and fast-forward merge diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md index 15eacc48dfe..88d745b0ce4 100644 --- a/doc/user/project/pipelines/settings.md +++ b/doc/user/project/pipelines/settings.md @@ -45,10 +45,10 @@ this filepath should be **relative** to the root. Here are some valid examples: -> * .gitlab-ci.yml -> * .my-custom-file.yml -> * my/path/.gitlab-ci.yml -> * my/path/.my-custom-file.yml +- `.gitlab-ci.yml` +- `.my-custom-file.yml` +- `my/path/.gitlab-ci.yml` +- `my/path/.my-custom-file.yml` ## Test coverage parsing diff --git a/doc/user/search/index.md b/doc/user/search/index.md index 78c1294346b..770cef42995 100644 --- a/doc/user/search/index.md +++ b/doc/user/search/index.md @@ -31,7 +31,7 @@ on the search field on the top-right of your screen: If you want to search for issues present in a specific project, navigate to a project's **Issues** tab, and click on the field **Search or filter results...**. It will -display a dropdown menu, from which you can add filters per author, assignee, milestone, +display a dropdown menu, from which you can add filters per author, assignee, milestone, label, weight, and 'my-reaction' (based on your emoji votes). When done, press **Enter** on your keyboard to filter the issues.  @@ -54,12 +54,12 @@ Selecting **Any** does the opposite. It returns results that have a non-empty va You can filter issues and merge requests by specific terms included in titles or descriptions. -* Syntax - * Searches look for all the words in a query, in any order. E.g.: searching +- Syntax + - Searches look for all the words in a query, in any order. E.g.: searching issues for `display bug` will return all issues matching both those words, in any order. - * To find the exact term, use double quotes: `"display bug"` -* Limitation - * For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching + - To find the exact term, use double quotes: `"display bug"` +- Limitation + - For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching issues for `included in titles` is same as `included titles`  diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md index ec5943fd51b..3fb553280d0 100644 --- a/doc/workflow/lfs/lfs_administration.md +++ b/doc/workflow/lfs/lfs_administration.md @@ -4,9 +4,9 @@ Documentation on how to use Git LFS are under [Managing large binary files with ## Requirements -* Git LFS is supported in GitLab starting with version 8.2. -* Support for object storage, such as AWS S3, was introduced in 10.0. -* Users need to install [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up. +- Git LFS is supported in GitLab starting with version 8.2. +- Support for object storage, such as AWS S3, was introduced in 10.0. +- Users need to install [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up. ## Configuration @@ -15,9 +15,9 @@ GitLab is installed on. There are various configuration options to help GitLab server administrators: -* Enabling/disabling Git LFS support -* Changing the location of LFS object storage -* Setting up object storage supported by [Fog](http://fog.io/about/provider_documentation.html) +- Enabling/disabling Git LFS support +- Changing the location of LFS object storage +- Setting up object storage supported by [Fog](http://fog.io/about/provider_documentation.html) ### Configuration for Omnibus installations @@ -229,11 +229,11 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-ce/merge_r ## Known limitations -* Support for removing unreferenced LFS objects was added in 8.14 onwards. -* LFS authentications via SSH was added with GitLab 8.12 -* Only compatible with the GitLFS client versions 1.1.0 and up, or 1.0.2. -* The storage statistics currently count each LFS object multiple times for - every project linking to it +- Support for removing unreferenced LFS objects was added in 8.14 onwards. +- LFS authentications via SSH was added with GitLab 8.12. +- Only compatible with the GitLFS client versions 1.1.0 and up, or 1.0.2. +- The storage statistics currently count each LFS object multiple times for + every project linking to it. [reconfigure gitlab]: ../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab" [restart gitlab]: ../../administration/restart_gitlab.md#installations-from-source "How to restart GitLab" diff --git a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md index d02e921fa84..da0243705aa 100644 --- a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md +++ b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md @@ -21,18 +21,18 @@ Documentation for GitLab instance administrators is under [LFS administration do ## Requirements -* Git LFS is supported in GitLab starting with version 8.2 -* Git LFS must be enabled under project settings -* [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up +- Git LFS is supported in GitLab starting with version 8.2 +- Git LFS must be enabled under project settings +- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up ## Known limitations -* Git LFS v1 original API is not supported since it was deprecated early in LFS +- Git LFS v1 original API is not supported since it was deprecated early in LFS development -* When SSH is set as a remote, Git LFS objects still go through HTTPS -* Any Git LFS request will ask for HTTPS credentials to be provided so a good Git +- When SSH is set as a remote, Git LFS objects still go through HTTPS +- Any Git LFS request will ask for HTTPS credentials to be provided so a good Git credentials store is recommended -* Git LFS always assumes HTTPS so if you have GitLab server on HTTP you will have +- Git LFS always assumes HTTPS so if you have GitLab server on HTTP you will have to add the URL to Git config manually (see [troubleshooting](#troubleshooting)) >**Note**: With 8.12 GitLab added LFS support to SSH. The Git LFS communication @@ -158,16 +158,16 @@ git lfs unlock --id=123 --force There are a couple of reasons why this error can occur: -* You don't have permissions to access certain LFS object +- You don't have permissions to access certain LFS object Check if you have permissions to push to the project or fetch from the project. -* Project is not allowed to access the LFS object +- Project is not allowed to access the LFS object LFS object you are trying to push to the project or fetch from the project is not available to the project anymore. Probably the object was removed from the server. -* Local git repository is using deprecated LFS API +- Local git repository is using deprecated LFS API ### Invalid status for `<url>` : 501 @@ -180,15 +180,15 @@ git lfs logs last If the status `error 501` is shown, it is because: -* Git LFS is not enabled in project settings. Check your project settings and +- Git LFS is not enabled in project settings. Check your project settings and enable Git LFS. -* Git LFS support is not enabled on the GitLab server. Check with your GitLab +- Git LFS support is not enabled on the GitLab server. Check with your GitLab administrator why Git LFS is not enabled on the server. See [LFS administration documentation](lfs_administration.md) for instructions on how to enable LFS support. -* Git LFS client version is not supported by GitLab server. Check your Git LFS +- Git LFS client version is not supported by GitLab server. Check your Git LFS version with `git lfs version`. Check the Git config of the project for traces of deprecated API with `git lfs -l`. If `batch = false` is set in the config, remove the line and try to update your Git LFS client. Only version 1.0.1 and diff --git a/doc/workflow/releases.md b/doc/workflow/releases.md index aa0d2a7f799..00cddda24a4 100644 --- a/doc/workflow/releases.md +++ b/doc/workflow/releases.md @@ -20,4 +20,3 @@ There are several ways to add release notes: ## Tags page with button to add or edit release notes for existing git tag  - diff --git a/doc/workflow/time_tracking.md b/doc/workflow/time_tracking.md index 8a75687e4f5..2bb140b99d0 100644 --- a/doc/workflow/time_tracking.md +++ b/doc/workflow/time_tracking.md @@ -8,8 +8,9 @@ requests within GitLab. ## Overview Time Tracking lets you: -* record the time spent working on an issue or a merge request, -* add an estimate of the amount of time needed to complete an issue or a merge + +- Record the time spent working on an issue or a merge request. +- Add an estimate of the amount of time needed to complete an issue or a merge request. You don't have to indicate an estimate to enter the time spent, and vice versa. @@ -62,11 +63,12 @@ To remove all the time spent at once, use `/remove_time_spent`. ## Configuration The following time units are available: -* months (mo) -* weeks (w) -* days (d) -* hours (h) -* minutes (m) + +- months (mo) +- weeks (w) +- days (d) +- hours (h) +- minutes (m) Default conversion rates are 1mo = 4w, 1w = 5d and 1d = 8h. |