Commit d98560c1 authored by Evan Read's avatar Evan Read

Make unordered lists conform to styleguide

- Also makes other minor Markdown fixes that were near the main fixes.
parent 710f2ec5
......@@ -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**
......
......@@ -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**
......
......@@ -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
......@@ -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
......
......@@ -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**
......
......@@ -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.
......
......@@ -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)
......@@ -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
# 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
......@@ -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.
......
......@@ -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:
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
# 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 }
......
......@@ -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
......
......@@ -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>
......
......@@ -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
......
......@@ -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.
......
......@@ -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)
......@@ -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.
......
......@@ -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 |
```
......
......@@ -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`
......@@ -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:
......
......@@ -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.