Fix most bare URLs in project
Linting rule not enabled for now because tooling produces false positives.
This commit is contained in:
Evan Read
Achilleas Pipinellis
parent
10a3ef2254
commit
d05eebe1dd
30 changed files with 114 additions and 107 deletions
|
|
@ -67,8 +67,8 @@ docs lint:
|
|||
- cd /tmp/gitlab-docs
|
||||
# Lint Markdown
|
||||
# https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
|
||||
- bundle exec mdl content/$DOCS_GITLAB_REPO_SUFFIX/**/*.md --rules \
|
||||
MD004,MD032
|
||||
- bundle exec mdl content/$DOCS_GITLAB_REPO_SUFFIX/**/*.md --ignore-front-matter --rules \
|
||||
MD004,MD032,MD034
|
||||
# Build HTML from Markdown
|
||||
- bundle exec nanoc
|
||||
# Check the internal links
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The steps below cover:
|
|||
|
||||
## Configuring Google LDAP client
|
||||
|
||||
1. Navigate to https://admin.google.com and sign in as a GSuite domain administrator.
|
||||
1. Navigate to <https://admin.google.com> and sign in as a GSuite domain administrator.
|
||||
|
||||
1. Go to **Apps > LDAP > Add Client**.
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ group, as opposed to the full DN.
|
|||
|
||||
## Global group memberships lock
|
||||
|
||||
"Lock memberships to LDAP synchronization" setting allows instance administrators
|
||||
"Lock memberships to LDAP synchronization" setting allows instance administrators
|
||||
to lock down user abilities to invite new members to a group. When enabled following happens:
|
||||
|
||||
1. Only administrator can manage memberships of any group including access levels.
|
||||
|
|
@ -198,14 +198,14 @@ to lock down user abilities to invite new members to a group. When enabled follo
|
|||
|
||||
NOTE: **Note:**
|
||||
These are cron formatted values. You can use a crontab generator to create
|
||||
these values, for example http://www.crontabgenerator.com/.
|
||||
these values, for example <http://www.crontabgenerator.com/>.
|
||||
|
||||
By default, GitLab will run a worker once per day at 01:30 a.m. server time to
|
||||
check and update GitLab users against LDAP.
|
||||
|
||||
You can manually configure LDAP user sync times by setting the
|
||||
following configuration values. The example below shows how to set LDAP user
|
||||
sync to run once every 12 hours at the top of the hour.
|
||||
sync to run once every 12 hours at the top of the hour.
|
||||
|
||||
**Omnibus installations**
|
||||
|
||||
|
|
@ -233,7 +233,7 @@ sync to run once every 12 hours at the top of the hour.
|
|||
|
||||
NOTE: **Note:**
|
||||
These are cron formatted values. You can use a crontab generator to create
|
||||
these values, for example http://www.crontabgenerator.com/.
|
||||
these values, for example <http://www.crontabgenerator.com/>.
|
||||
|
||||
By default, GitLab will run a group sync process every hour, on the hour.
|
||||
|
||||
|
|
@ -245,8 +245,8 @@ for installations with a large number of LDAP users. Please review the
|
|||
your installation compares before proceeding.
|
||||
|
||||
You can manually configure LDAP group sync times by setting the
|
||||
following configuration values. The example below shows how to set group
|
||||
sync to run once every 2 hours at the top of the hour.
|
||||
following configuration values. The example below shows how to set group
|
||||
sync to run once every 2 hours at the top of the hour.
|
||||
|
||||
**Omnibus installations**
|
||||
|
||||
|
|
|
|||
|
|
@ -383,7 +383,6 @@ The prerequisites for a HA Redis setup are the following:
|
|||
redis['password'] = 'redis-password-goes-here'
|
||||
```
|
||||
|
||||
|
||||
1. Only the primary GitLab application server should handle migrations. To
|
||||
prevent database migrations from running on upgrade, add the following
|
||||
configuration to your `/etc/gitlab/gitlab.rb` file:
|
||||
|
|
@ -396,7 +395,7 @@ The prerequisites for a HA Redis setup are the following:
|
|||
|
||||
> Note: You can specify multiple roles like sentinel and redis as:
|
||||
> roles ['redis_sentinel_role', 'redis_master_role']. Read more about high
|
||||
> availability roles at https://docs.gitlab.com/omnibus/roles/
|
||||
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
|
||||
|
||||
### Step 2. Configuring the slave Redis instances
|
||||
|
||||
|
|
@ -445,7 +444,7 @@ The prerequisites for a HA Redis setup are the following:
|
|||
|
||||
> Note: You can specify multiple roles like sentinel and redis as:
|
||||
> roles ['redis_sentinel_role', 'redis_slave_role']. Read more about high
|
||||
> availability roles at https://docs.gitlab.com/omnibus/roles/
|
||||
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -291,7 +291,6 @@ Parameters:
|
|||
| `merge_requests_events` | boolean | false | Enable notifications for merge request events |
|
||||
| `tag_push_events` | boolean | false | Enable notifications for tag push events |
|
||||
|
||||
|
||||
### Delete Drone CI service
|
||||
|
||||
Delete Drone CI service for a project.
|
||||
|
|
@ -744,7 +743,7 @@ Parameters:
|
|||
| --------- | ---- | -------- | ----------- |
|
||||
| `username` | string | yes | The username of a Packagist account |
|
||||
| `token` | string | yes | API token to the Packagist server |
|
||||
| `server` | boolean | no | URL of the Packagist server. Leave blank for default: https://packagist.org |
|
||||
| `server` | boolean | no | URL of the Packagist server. Leave blank for default: <https://packagist.org> |
|
||||
| `push_events` | boolean | false | Enable notifications for push events |
|
||||
| `merge_requests_events` | boolean | false | Enable notifications for merge request events |
|
||||
| `tag_push_events` | boolean | false | Enable notifications for tag push events |
|
||||
|
|
@ -1161,7 +1160,7 @@ PUT /projects/:id/services/jenkins
|
|||
|
||||
Parameters:
|
||||
|
||||
- `jenkins_url` (**required**) - Jenkins URL like http://jenkins.example.com
|
||||
- `jenkins_url` (**required**) - Jenkins URL like `http://jenkins.example.com`
|
||||
- `project_name` (**required**) - The URL-friendly project name. Example: my_project_name
|
||||
- `username` (optional) - A user with access to the Jenkins server, if applicable
|
||||
- `password` (optional) - The password of the user
|
||||
|
|
@ -1196,7 +1195,7 @@ PUT /projects/:id/services/jenkins-deprecated
|
|||
|
||||
Parameters:
|
||||
|
||||
- `project_url` (**required**) - Jenkins project URL like http://jenkins.example.com/job/my-project/
|
||||
- `project_url` (**required**) - Jenkins project URL like `http://jenkins.example.com/job/my-project/`
|
||||
- `multiproject_enabled` (optional) - Multi-project mode is configured in Jenkins GitLab Hook plugin
|
||||
- `pass_unstable` (optional) - Unstable builds will be treated as passing
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ A complete architecture diagram is available in our
|
|||
|
||||
|
||||
|
||||
<!--
|
||||
<!--
|
||||
To update this diagram, GitLab team members can edit this source file:
|
||||
https://docs.google.com/drawings/d/1fBzAyklyveF-i-2q-OHUIqDkYfjjxC4mq5shwKSZHLs/edit.
|
||||
-->
|
||||
|
|
@ -304,7 +304,7 @@ GitLab is comprised of a large number of services that all log. We started bundl
|
|||
- Configuration: [Omnibus][mattermost-omnibus], [Charts][mattermost-charts]
|
||||
- Layer: Core Service (Processor)
|
||||
|
||||
Mattermost is an open source, private cloud, Slack-alternative from https://mattermost.com.
|
||||
Mattermost is an open source, private cloud, Slack-alternative from <https://mattermost.com>.
|
||||
|
||||
#### MinIO
|
||||
|
||||
|
|
@ -321,7 +321,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp
|
|||
- Layer: Core Service (Processor)
|
||||
- Process: `nginx`
|
||||
|
||||
Nginx as an ingress port for all HTTP requests and routes them to the approriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
|
||||
Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
|
||||
|
||||
#### Node Exporter
|
||||
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ The table below shows what kind of documentation goes where.
|
|||
applies to images.
|
||||
1. For image files, do not exceed 100KB.
|
||||
1. Do not upload video files to the product repositories.
|
||||
[Link or embed videos](#videos) instead.
|
||||
[Link or embed videos](#videos) instead.
|
||||
1. There are four main directories, `user`, `administration`, `api` and `development`.
|
||||
1. The `doc/user/` directory has five main subdirectories: `project/`, `group/`,
|
||||
`profile/`, `dashboard/` and `admin_area/`.
|
||||
|
|
@ -179,7 +179,7 @@ The table below shows what kind of documentation goes where.
|
|||
If you are unsure where a document or a content addition should live, this should
|
||||
not stop you from authoring and contributing. You can use your best judgment and
|
||||
then ask the reviewer of your MR to confirm your decision, and/or ask a technical writer
|
||||
at any stage in the process. The techncial writing team will review all documentation
|
||||
at any stage in the process. The technical writing team will review all documentation
|
||||
changes, regardless, and can move content if there is a better place for it.
|
||||
|
||||
### Avoid duplication
|
||||
|
|
@ -476,7 +476,7 @@ Do not upload videos to the product repositories. [Link](#link-to-video) or [emb
|
|||
|
||||
### Link to video
|
||||
|
||||
To link out to a video, include a YouTube icon so that readers can
|
||||
To link out to a video, include a YouTube icon so that readers can
|
||||
quickly and easily scan the page for videos before reading:
|
||||
|
||||
```md
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Search queries are generated by the concerns found in [ee/app/models/concerns/el
|
|||
|
||||
## Existing Analyzers/Tokenizers/Filters
|
||||
|
||||
These are all defined in https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/lib/elasticsearch/git/model.rb
|
||||
These are all defined in <https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/lib/elasticsearch/git/model.rb>
|
||||
|
||||
### Analyzers
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ easy to maintain, and performant for the end-user.
|
|||
## Rules
|
||||
|
||||
### Utility Classes
|
||||
|
||||
As part of the effort for [cleaning up our CSS and moving our components into GitLab-UI](https://gitlab.com/groups/gitlab-org/-/epics/950)
|
||||
led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/20623) we prefer the use of utility classes over adding new CSS. However, complex CSS can be addressed by adding component classes.
|
||||
|
||||
|
|
@ -31,12 +32,12 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
|
|||
|
||||
#### When should I create component classes?
|
||||
|
||||
We recommend a "utility-first" approach.
|
||||
We recommend a "utility-first" approach.
|
||||
|
||||
1. Start with utility classes.
|
||||
2. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
|
||||
|
||||
This encourages an organic growth of component classes and prevents the creation of one-off unreusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`).
|
||||
This encourages an organic growth of component classes and prevents the creation of one-off unreusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`).
|
||||
|
||||
Examples of component classes that were created using "utility-first" include:
|
||||
|
||||
|
|
@ -45,8 +46,8 @@ Examples of component classes that were created using "utility-first" include:
|
|||
|
||||
Inspiration:
|
||||
|
||||
- https://tailwindcss.com/docs/utility-first
|
||||
- https://tailwindcss.com/docs/extracting-components
|
||||
- <https://tailwindcss.com/docs/utility-first>
|
||||
- <https://tailwindcss.com/docs/extracting-components>
|
||||
|
||||
### Naming
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,9 @@ provided as a prop to the main component.
|
|||
Be sure to read about [page-specific JavaScript][page_specific_javascript].
|
||||
|
||||
### Bootstrapping Gotchas
|
||||
|
||||
#### Providing data from HAML to JavaScript
|
||||
|
||||
While mounting a Vue application may be a need to provide data from Rails to JavaScript.
|
||||
To do that, provide the data through `data` attributes in the HTML element and query them while mounting the application.
|
||||
|
||||
|
|
@ -83,7 +85,8 @@ document.addEventListener('DOMContentLoaded', () => new Vue({
|
|||
```
|
||||
|
||||
#### Accessing the `gl` object
|
||||
When we need to query the `gl` object for data that won't change during the application's life cyle, we should do it in the same place where we query the DOM.
|
||||
|
||||
When we need to query the `gl` object for data that won't change during the application's life cycle, we should do it in the same place where we query the DOM.
|
||||
By following this practice, we can avoid the need to mock the `gl` object, which will make tests easier.
|
||||
It should be done while initializing our Vue instance, and the data should be provided as `props` to the main component:
|
||||
|
||||
|
|
@ -118,6 +121,7 @@ You can read more about components in Vue.js site, [Component System][component-
|
|||
### A folder for the Store
|
||||
|
||||
#### Vuex
|
||||
|
||||
Check this [page](vuex.md) for more details.
|
||||
|
||||
### Mixing Vue and jQuery
|
||||
|
|
@ -212,6 +216,7 @@ describe('Todos App', () => {
|
|||
```
|
||||
|
||||
### `mountComponent` helper
|
||||
|
||||
There is a helper in `spec/javascripts/helpers/vue_mount_component_helper.js` that allows you to mount a component with the given props:
|
||||
|
||||
```javascript
|
||||
|
|
@ -225,10 +230,12 @@ const vm = mountComponent(Component, data);
|
|||
```
|
||||
|
||||
### Test the component's output
|
||||
|
||||
The main return value of a Vue component is the rendered output. In order to test the component we
|
||||
need to test the rendered output. [Vue][vue-test] guide's to unit test show us exactly that:
|
||||
|
||||
## Vue.js Expert Role
|
||||
|
||||
One should apply to be a Vue.js expert by opening an MR when the Merge Request's they create and review show:
|
||||
|
||||
- Deep understanding of Vue and Vuex reactivy
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
# Feature flags process
|
||||
|
||||
## Feature flags for user applications
|
||||
|
||||
This document only covers feature flags used in the development of GitLab
|
||||
|
|
@ -12,12 +13,12 @@ should be leveraged:
|
|||
|
||||
- By default, the feature flags should be **off**.
|
||||
- Feature flags should remain in the codebase for as short period as possible
|
||||
to reduce the need for feature flag accounting.
|
||||
to reduce the need for feature flag accounting.
|
||||
- The person operating with feature flags is responsible for clearly communicating
|
||||
the status of a feature behind the feature flag with responsible stakeholders.
|
||||
the status of a feature behind the feature flag with responsible stakeholders.
|
||||
- Merge requests that make changes hidden behind a feature flag, or remove an
|
||||
existing feature flag because a feature is deemed stable must have the
|
||||
~"feature flag" label assigned.
|
||||
existing feature flag because a feature is deemed stable must have the
|
||||
~"feature flag" label assigned.
|
||||
|
||||
One might be tempted to think that feature flags will delay the release of a
|
||||
feature by at least one month (= one release). This is not the case. A feature
|
||||
|
|
@ -64,12 +65,12 @@ to be included in the final self-managed release.
|
|||
In addition to this, the feature behind feature flag should:
|
||||
|
||||
- Run in all GitLab.com environments for a sufficient period of time. This time
|
||||
period depends on the feature behind the feature flag, but as a general rule of
|
||||
thumb 2-4 working days should be sufficient to gather enough feedback.
|
||||
period depends on the feature behind the feature flag, but as a general rule of
|
||||
thumb 2-4 working days should be sufficient to gather enough feedback.
|
||||
- The feature should be exposed to all users within the GitLab.com plan during
|
||||
the above mentioned period of time. Exposing the feature to a smaller percentage
|
||||
or only a group of users might not expose a sufficient amount of information to aid in
|
||||
making a decision on feature stability.
|
||||
the above mentioned period of time. Exposing the feature to a smaller percentage
|
||||
or only a group of users might not expose a sufficient amount of information to aid in
|
||||
making a decision on feature stability.
|
||||
|
||||
While rare, release managers may decide to reject picking or revert a change in
|
||||
a stable branch, even when feature flags are used. This might be necessary if
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ are as follows:
|
|||
(`pool.source_project`)
|
||||
|
||||
> TODO Fix invalid SQL data for pools created prior to GitLab 11.11
|
||||
> https://gitlab.com/gitlab-org/gitaly/issues/1653.
|
||||
> <https://gitlab.com/gitlab-org/gitaly/issues/1653>.
|
||||
|
||||
### Assumptions
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ are as follows:
|
|||
repository.
|
||||
|
||||
> TODO should forks of forks be deduplicated?
|
||||
> https://gitlab.com/gitlab-org/gitaly/issues/1532
|
||||
> <https://gitlab.com/gitlab-org/gitaly/issues/1532>
|
||||
|
||||
### Consequences
|
||||
|
||||
|
|
@ -215,4 +215,4 @@ the secondary, at which stage Git objects will get deduplicated.
|
|||
|
||||
> TODO How do we handle the edge case where at the time the Geo
|
||||
> secondary tries to create the pool repository, the source project does
|
||||
> not exist? https://gitlab.com/gitlab-org/gitaly/issues/1533
|
||||
> not exist? <https://gitlab.com/gitlab-org/gitaly/issues/1533>
|
||||
|
|
|
|||
|
|
@ -424,7 +424,7 @@ might find using these gems more convenient:
|
|||
### Examples
|
||||
|
||||
You may find some useful examples in this snippet:
|
||||
https://gitlab.com/gitlab-org/gitlab-ce/snippets/33946
|
||||
<https://gitlab.com/gitlab-org/gitlab-ce/snippets/33946>
|
||||
|
||||
[#15607]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15607
|
||||
[yorickpeterse]: https://gitlab.com/yorickpeterse
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Similar to source browsing, is [Documentation browsing](https://github.com/pry/p
|
|||
|
||||
### Command history
|
||||
|
||||
With <kdb>Ctrl+R</kbd> you can search your [command history](https://github.com/pry/pry/wiki/History).
|
||||
With **Ctrl+R** you can search your [command history](https://github.com/pry/pry/wiki/History).
|
||||
|
||||
## Stepping
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/
|
||||
redirect_to: 'https://docs.gitlab.com/charts/'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/
|
||||
redirect_to: 'https://docs.gitlab.com/charts/'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/runner/install/kubernetes.html
|
||||
redirect_to: 'https://docs.gitlab.com/runner/install/kubernetes.html'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/runner/install/kubernetes.html).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/
|
||||
redirect_to: 'https://docs.gitlab.com/charts/'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/cloud/
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/cloud/'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/cloud/).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/cloud/eks.html
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/cloud/eks.html'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/cloud/eks.html).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/deployment.html#networking-and-dns
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/deployment.html#networking-and-dns'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/deployment.html#networking-and-dns).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/deployment.html#rbac
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/deployment.html#rbac'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/deployment.html#rbac).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/tools.html
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/tools.html'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/tools.html).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
redirect_to: https://docs.gitlab.com/charts/installation/tools.html
|
||||
redirect_to: 'https://docs.gitlab.com/charts/installation/tools.html'
|
||||
---
|
||||
|
||||
This document was moved to [another location](https://docs.gitlab.com/charts/installation/tools.html).
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ The following Elasticsearch settings are available:
|
|||
| `Elasticsearch indexing` | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
|
||||
| `Use the new repository indexer (beta)` | Perform repository indexing using [GitLab Elasticsearch Indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). |
|
||||
| `Search with Elasticsearch enabled` | Enables/disables using Elasticsearch in search. |
|
||||
| `URL` | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., "http://host1, https://host2:9200"). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
|
||||
| `URL` | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
|
||||
| `Number of Elasticsearch shards` | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
|
||||
| `Number of Elasticsearch replicas` | Each Elasticsearch shard can have a number of replicas. These are a complete copy of the shard, and can provide increased query performance or resilience against hardware failure. Increasing this value will greatly increase total disk space required by the index. |
|
||||
| `Limit namespaces and projects that can be indexed` | Enabling this will allow you to select namespaces and projects to index. All other namespaces and projects will use database search instead. Please note that if you enable this option but do not select any namespaces or projects, none will be indexed. [Read more below](#limiting-namespaces-and-projects).
|
||||
|
|
@ -156,7 +156,7 @@ If no namespaces or projects are selected, no Elasticsearch indexing will take p
|
|||
CAUTION: **Warning**:
|
||||
If you have already indexed your instance, you will have to regenerate the index in order to delete all existing data
|
||||
for filtering to work correctly. To do this run the rake tasks `gitlab:elastic:create_empty_index` and
|
||||
`gitlab:elastic:clear_index_status` Afterwards, removing a namespace or a projeect from the list will delete the data
|
||||
`gitlab:elastic:clear_index_status`. Afterwards, removing a namespace or a project from the list will delete the data
|
||||
from the Elasticsearch index as expected.
|
||||
|
||||
## Disabling Elasticsearch
|
||||
|
|
@ -304,7 +304,7 @@ For Elasticsearch 6.x, before proceeding with the force merge, the index should
|
|||
```bash
|
||||
curl --request PUT localhost:9200/gitlab-production/_settings --data '{
|
||||
"settings": {
|
||||
"index.blocks.write": true
|
||||
"index.blocks.write": true
|
||||
} }'
|
||||
```
|
||||
|
||||
|
|
@ -319,7 +319,7 @@ After this, if your index is in read-only, switch back to read-write:
|
|||
```bash
|
||||
curl --request PUT localhost:9200/gitlab-production/_settings --data '{
|
||||
"settings": {
|
||||
"index.blocks.write": false
|
||||
"index.blocks.write": false
|
||||
} }'
|
||||
```
|
||||
|
||||
|
|
@ -392,9 +392,9 @@ When performing a search, the GitLab index will use the following scopes:
|
|||
|
||||
Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted. However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases. Elasticsearch does intelligent merging of segments in order to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index.
|
||||
|
||||
In general, we recommend simply letting Elasticseach merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_
|
||||
In general, we recommend simply letting Elasticsearch merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_
|
||||
|
||||
However, some larger installations may wish to tune the merge policy settings:
|
||||
However, some larger installations may wish to tune the merge policy settings:
|
||||
|
||||
- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently.
|
||||
|
||||
|
|
@ -425,14 +425,14 @@ Here are some common pitfalls and how to overcome them:
|
|||
- **How can I verify my GitLab instance is using Elasticsearch?**
|
||||
|
||||
The easiest method is via the rails console (`sudo gitlab-rails console`) by running the following:
|
||||
|
||||
|
||||
```ruby
|
||||
u = User.find_by_username('your-username')
|
||||
s = SearchService.new(u, {:search => 'search_term'})
|
||||
pp s.search_objects.class.name
|
||||
```
|
||||
|
||||
If you see `Elasticsearch::Model::Response::Records`, you are using Elasticsearch.
|
||||
|
||||
If you see `Elasticsearch::Model::Response::Records`, you are using Elasticsearch.
|
||||
|
||||
- **I updated GitLab and now I can't find anything**
|
||||
|
||||
|
|
@ -443,23 +443,23 @@ Here are some common pitfalls and how to overcome them:
|
|||
- **I indexed all the repositories but I can't find anything**
|
||||
|
||||
Make sure you indexed all the database data [as stated above](#adding-gitlabs-data-to-the-elasticsearch-index).
|
||||
|
||||
|
||||
Beyond that, check via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) to see if the data shows up on the Elasticsearch side.
|
||||
|
||||
|
||||
If it shows up via the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html), check that it shows up via the rails console (`sudo gitlab-rails console`):
|
||||
|
||||
|
||||
```ruby
|
||||
u = User.find_by_username('your-username')
|
||||
s = SearchService.new(u, {:search => 'search_term', :scope => ‘blobs’})
|
||||
pp s.search_objects.to_a
|
||||
```
|
||||
|
||||
|
||||
See [Elasticsearch Index Scopes](elasticsearch.md#elasticsearch-index-scopes) for more information on searching for specific types of data.
|
||||
|
||||
- **I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything**
|
||||
|
||||
You will need to re-run all the rake tasks to re-index the database, repositories, and wikis.
|
||||
|
||||
|
||||
- **The indexing process is taking a very long time**
|
||||
|
||||
The more data present in your GitLab instance, the longer the indexing process takes.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Please note that you need to be a group owner to associate a group to your subsc
|
|||
To see the status of your GitLab.com subscription, you can click on the Billings
|
||||
section of the relevant namespace:
|
||||
|
||||
- For individuals, this is located at https://gitlab.com/profile/billings under
|
||||
- For individuals, this is located at <https://gitlab.com/profile/billings> under
|
||||
in your Settings,
|
||||
- For groups, this is located under the group's Settings dropdown, under Billing.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Consult the [Asciidoctor User Manual](https://asciidoctor.org/docs/user-manual)
|
|||
## Syntax
|
||||
|
||||
Here's a brief reference of the most commonly used AsciiDoc syntax.
|
||||
You can find the full documentation for the AsciiDoc syntax at https://asciidoctor.org/docs.
|
||||
You can find the full documentation for the AsciiDoc syntax at <https://asciidoctor.org/docs>.
|
||||
|
||||
### Paragraphs
|
||||
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ changing how standard markdown is used:
|
|||
| [links](#links) | [automatically linking URLs](#url-auto-linking) |
|
||||
|
||||
## New GFM markdown extensions
|
||||
|
||||
|
||||
### Colors
|
||||
|
||||
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#colors).
|
||||
|
|
@ -136,26 +136,26 @@ Supported formats (named colors are not supported):
|
|||
Color written inside backticks will be followed by a color "chip":
|
||||
|
||||
```markdown
|
||||
`#F00`
|
||||
`#F00A`
|
||||
`#FF0000`
|
||||
`#FF0000AA`
|
||||
`RGB(0,255,0)`
|
||||
`RGB(0%,100%,0%)`
|
||||
`RGBA(0,255,0,0.3)`
|
||||
`HSL(540,70%,50%)`
|
||||
`HSLA(540,70%,50%,0.3)`
|
||||
`#F00`
|
||||
`#F00A`
|
||||
`#FF0000`
|
||||
`#FF0000AA`
|
||||
`RGB(0,255,0)`
|
||||
`RGB(0%,100%,0%)`
|
||||
`RGBA(0,255,0,0.3)`
|
||||
`HSL(540,70%,50%)`
|
||||
`HSLA(540,70%,50%,0.3)`
|
||||
```
|
||||
|
||||
`#F00`
|
||||
`#F00A`
|
||||
`#FF0000`
|
||||
`#FF0000AA`
|
||||
`RGB(0,255,0)`
|
||||
`RGB(0%,100%,0%)`
|
||||
`RGBA(0,255,0,0.3)`
|
||||
`HSL(540,70%,50%)`
|
||||
`HSLA(540,70%,50%,0.3)`
|
||||
`#F00`
|
||||
`#F00A`
|
||||
`#FF0000`
|
||||
`#FF0000AA`
|
||||
`RGB(0,255,0)`
|
||||
`RGB(0%,100%,0%)`
|
||||
`RGBA(0,255,0,0.3)`
|
||||
`HSL(540,70%,50%)`
|
||||
`HSLA(540,70%,50%,0.3)`
|
||||
|
||||
### Diagrams and flowcharts using Mermaid
|
||||
|
||||
|
|
@ -359,7 +359,7 @@ version to reference other projects from the same namespace.
|
|||
|
||||
GFM will recognize the following:
|
||||
|
||||
| references | input | cross-project reference | shortcut within same namespace |
|
||||
| references | input | cross-project reference | shortcut within same namespace |
|
||||
| :------------------------------ | :------------------------- | :-------------------------------------- | :----------------------------- |
|
||||
| specific user | `@user_name` | | |
|
||||
| specific group | `@group_name` | | |
|
||||
|
|
@ -704,7 +704,7 @@ but_emphasis is_desired _here_
|
|||
```
|
||||
|
||||
perform_complicated_task
|
||||
|
||||
|
||||
do_this_and_do_that_and_another_thing
|
||||
|
||||
but_emphasis is_desired _here_
|
||||
|
|
@ -715,12 +715,12 @@ If you wish to emphasize only a part of a word, it can still be done with asteri
|
|||
|
||||
```md
|
||||
perform*complicated*task
|
||||
|
||||
|
||||
do*this*and*do*that*and*another thing
|
||||
```
|
||||
|
||||
perform*complicated*task
|
||||
|
||||
|
||||
do*this*and*do*that*and*another thing
|
||||
|
||||
### Footnotes
|
||||
|
|
@ -910,9 +910,9 @@ are separated into their own lines:
|
|||
|
||||
<dt>Markdown in HTML</dt>
|
||||
<dd>
|
||||
|
||||
|
||||
Does *not* work **very** well. HTML tags will always work.
|
||||
|
||||
|
||||
</dd>
|
||||
</dl>
|
||||
```
|
||||
|
|
@ -925,9 +925,9 @@ are separated into their own lines:
|
|||
|
||||
<dt>Markdown in HTML</dt>
|
||||
<dd>
|
||||
|
||||
|
||||
Does <em>not</em> work <b>very</b> well. HTML tags will always work.
|
||||
|
||||
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
|
|
@ -1045,14 +1045,14 @@ A new line due to the previous backslash.
|
|||
|
||||
First paragraph.
|
||||
Another line in the same paragraph.
|
||||
A third line in the same paragraph, but this time ending with two spaces.
|
||||
A third line in the same paragraph, but this time ending with two spaces.
|
||||
A new line directly under the first paragraph.
|
||||
|
||||
<!-- (Do *NOT* remove the two ending whitespaces in the second line) -->
|
||||
<!-- (They are needed for the Markdown text to render correctly on docs.gitlab.com, the backslash works fine inside GitLab itself) -->
|
||||
|
||||
Second paragraph.
|
||||
Another line, this time ending with a backslash.
|
||||
Another line, this time ending with a backslash.
|
||||
A new line due to the previous backslash.
|
||||
|
||||
### Links
|
||||
|
|
@ -1123,12 +1123,12 @@ GFM will autolink almost any URL you put into your text:
|
|||
- http://localhost:3000
|
||||
```
|
||||
|
||||
- https://www.google.com
|
||||
- https://google.com/
|
||||
- ftp://ftp.us.debian.org/debian/
|
||||
- smb://foo/bar/baz
|
||||
- irc://irc.freenode.net/gitlab
|
||||
- http://localhost:3000
|
||||
- <https://www.google.com>
|
||||
- <https://google.com/>
|
||||
- <ftp://ftp.us.debian.org/debian/>
|
||||
- <smb://foo/bar/baz>
|
||||
- <irc://irc.freenode.net/gitlab>
|
||||
- <http://localhost:3000>
|
||||
|
||||
### Lists
|
||||
|
||||
|
|
@ -1229,7 +1229,7 @@ while the equation for the theory of relativity is E = mc<sup>2</sup>.
|
|||
|
||||
Tables aren't part of the core Markdown spec, but they are part of GFM.
|
||||
|
||||
1. The first line contains the headers, separated by "pipes" (`|`).
|
||||
1. The first line contains the headers, separated by "pipes" (`|`).
|
||||
1. The second line separates the headers from the cells, and must contain three or more dashes.
|
||||
1. The third, and any following lines, contain the cell values.
|
||||
- You **can't** have cells separated over many lines in the markdown, they must be kept to single lines,
|
||||
|
|
|
|||
|
|
@ -40,14 +40,14 @@ some steps to migrate your projects. There is no automatic import since GitLab
|
|||
doesn't know anything about any projects which existed on Gemnasium.com.
|
||||
Security features are free for public (open-source) projects hosted on GitLab.com.
|
||||
|
||||
### If your project is hosted on GitLab (https://gitlab.com / self-hosted)
|
||||
### If your project is hosted on GitLab (`https://gitlab.com` / self-hosted)
|
||||
|
||||
You're almost set! If you're already using
|
||||
[Auto DevOps](../../../topics/autodevops/), you are already covered.
|
||||
Otherwise, you must configure your `.gitlab-ci.yml` according to the
|
||||
[dependency scanning page](../../application_security/dependency_scanning/index.md).
|
||||
|
||||
### If your project is hosted on GitHub (https://github.com / GitHub Enterprise)
|
||||
### If your project is hosted on GitHub (`https://github.com` / GitHub Enterprise)
|
||||
|
||||
Since [GitLab 10.6 comes with GitHub integration](https://about.gitlab.com/features/github/),
|
||||
GitLab users can now create a CI/CD project in GitLab connected to an external
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ and is automatically configured on [GitHub import](../../../integration/github.m
|
|||
This integration requires a [GitHub API token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/)
|
||||
with `repo:status` access granted:
|
||||
|
||||
1. Go to your "Personal access tokens" page at https://github.com/settings/tokens
|
||||
1. Go to your "Personal access tokens" page at <https://github.com/settings/tokens>
|
||||
1. Click "Generate New Token"
|
||||
1. Ensure that `repo:status` is checked and click "Generate token"
|
||||
1. Copy the generated token to use on GitLab
|
||||
|
|
|
|||
Loading…
Reference in a new issue