Commit 1464b1e0 authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read

Fix markdown to reduce number of kramdown warnings

Add backticks around square brackets, or fix links, as necessary.
parent ae7a4397
[//]: # (Do *NOT* modify this file in EE documentation. All changes in this)
[//]: # (file should happen in CE, too. If the change is EE-specific, put)
[//]: # (it in `ldap-ee.md`.)
<!-- If the change is EE-specific, put it in `ldap-ee.md`, NOT here. -->
# LDAP
......
......@@ -30,7 +30,7 @@ We now require this change as we use this password to enable the Foreign Data Wr
the Geo Tracking Database. We are also improving security by disabling the use of **trust**
authentication method.
1. **[primary]** Login to your **primary** node and run:
1. **(primary)** Login to your **primary** node and run:
```sh
gitlab-ctl pg-password-md5 gitlab
......@@ -57,14 +57,14 @@ authentication method.
postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','1.2.3.4/32'] # <- Remove this
```
1. **[primary]** Reconfigure and restart:
1. **(primary)** Reconfigure and restart:
```sh
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
1. **[secondary]** Login to all **secondary** nodes and edit `/etc/gitlab/gitlab.rb`:
1. **(secondary)** Login to all **secondary** nodes and edit `/etc/gitlab/gitlab.rb`:
```ruby
# Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
......@@ -88,7 +88,7 @@ authentication method.
postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/32','5.6.7.8/32'] # <- Remove this
```
1. **[secondary]** Reconfigure and restart:
1. **(secondary)** Reconfigure and restart:
```sh
sudo gitlab-ctl reconfigure
......@@ -169,7 +169,7 @@ After you've verified that HTTP/HTTPS replication is working, you should remove
the now-unused SSH keys from your secondaries, as they may cause problems if the
**secondary** node if ever promoted to a **primary** node:
1. **[secondary]** Login to **all** your **secondary** nodes and run:
1. **(secondary)** Login to **all** your **secondary** nodes and run:
```ruby
sudo -u git -H rm ~git/.ssh/id_rsa ~git/.ssh/id_rsa.pub
......@@ -260,24 +260,24 @@ Make sure to follow the steps in the exact order as they appear below and pay
extra attention in what node (either **primary** or **secondary**) you execute them! Each step
is prepended with the relevant node for better clarity:
1. **[secondary]** Login to **all** your **secondary** nodes and stop all services:
1. **(secondary)** Login to **all** your **secondary** nodes and stop all services:
```ruby
sudo gitlab-ctl stop
```
1. **[secondary]** Make a backup of the `recovery.conf` file on **all**
1. **(secondary)** Make a backup of the `recovery.conf` file on **all**
**secondary** nodes to preserve PostgreSQL's credentials:
```sh
sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/
```
1. **[primary]** Update the **primary** node to GitLab 9.0 following the
1. **(primary)** Update the **primary** node to GitLab 9.0 following the
[regular update docs][update]. At the end of the update, the **primary** node
will be running with PostgreSQL 9.6.
1. **[primary]** To prevent a de-synchronization of the repository replication,
1. **(primary)** To prevent a de-synchronization of the repository replication,
stop all services except `postgresql` as we will use it to re-initialize the
**secondary** node's database:
......@@ -286,55 +286,55 @@ is prepended with the relevant node for better clarity:
sudo gitlab-ctl start postgresql
```
1. **[secondary]** Run the following steps on each of the **secondary** nodes:
1. **(secondary)** Run the following steps on each of the **secondary** nodes:
1. **[secondary]** Stop all services:
1. **(secondary)** Stop all services:
```sh
sudo gitlab-ctl stop
```
1. **[secondary]** Prevent running database migrations:
1. **(secondary)** Prevent running database migrations:
```sh
sudo touch /etc/gitlab/skip-auto-migrations
```
1. **[secondary]** Move the old database to another directory:
1. **(secondary)** Move the old database to another directory:
```sh
sudo mv /var/opt/gitlab/postgresql{,.bak}
```
1. **[secondary]** Update to GitLab 9.0 following the [regular update docs][update].
1. **(secondary)** Update to GitLab 9.0 following the [regular update docs][update].
At the end of the update, the node will be running with PostgreSQL 9.6.
1. **[secondary]** Make sure all services are up:
1. **(secondary)** Make sure all services are up:
```sh
sudo gitlab-ctl start
```
1. **[secondary]** Reconfigure GitLab:
1. **(secondary)** Reconfigure GitLab:
```sh
sudo gitlab-ctl reconfigure
```
1. **[secondary]** Run the PostgreSQL upgrade command:
1. **(secondary)** Run the PostgreSQL upgrade command:
```sh
sudo gitlab-ctl pg-upgrade
```
1. **[secondary]** See the stored credentials for the database that you will
1. **(secondary)** See the stored credentials for the database that you will
need to re-initialize the replication:
```sh
sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf
```
1. **[secondary]** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
embedded paths if necessary:
```
......@@ -381,28 +381,28 @@ is prepended with the relevant node for better clarity:
sudo service postgresql start
```
1. **[secondary]** Run the recovery script using the credentials from the
1. **(secondary)** Run the recovery script using the credentials from the
previous step:
```sh
sudo bash /tmp/replica.sh
```
1. **[secondary]** Reconfigure GitLab:
1. **(secondary)** Reconfigure GitLab:
```sh
sudo gitlab-ctl reconfigure
```
1. **[secondary]** Start all services:
1. **(secondary)** Start all services:
```sh
sudo gitlab-ctl start
```
1. **[secondary]** Repeat the steps for the remaining **secondary** nodes.
1. **(secondary)** Repeat the steps for the remaining **secondary** nodes.
1. **[primary]** After all **secondary** nodes are updated, start all services in
1. **(primary)** After all **secondary** nodes are updated, start all services in
**primary** node:
```sh
......
......@@ -394,7 +394,7 @@ The prerequisites for a HA Redis setup are the following:
1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect.
> Note: You can specify multiple roles like sentinel and redis as:
> roles ['redis_sentinel_role', 'redis_master_role']. Read more about high
> `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about high
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
### Step 2. Configuring the slave Redis instances
......@@ -443,7 +443,7 @@ The prerequisites for a HA Redis setup are the following:
1. Go through the steps again for all the other slave nodes.
> Note: You can specify multiple roles like sentinel and redis as:
> roles ['redis_sentinel_role', 'redis_slave_role']. Read more about high
> `roles ['redis_sentinel_role', 'redis_slave_role']`. Read more about high
> availability roles at <https://docs.gitlab.com/omnibus/roles/>.
---
......
......@@ -108,7 +108,7 @@ Some basic Ruby runtime metrics are available:
[GC.stat]: https://ruby-doc.org/core-2.3.0/GC.html#method-c-stat
## Puma Metrics **[EXPERIMENTAL]**
## Puma Metrics **(EXPERIMENTAL)**
When Puma is used instead of Unicorn, following metrics are available:
......
......@@ -78,7 +78,7 @@ future GitLab releases.**
| `CI_PIPELINE_ID` | 8.10 | all | The unique id of the current pipeline that GitLab CI uses internally |
| `CI_PIPELINE_IID` | 11.0 | all | The unique id of the current pipeline scoped to project |
| `CI_PIPELINE_SOURCE` | 10.0 | all | Indicates how the pipeline was triggered. Possible options are: `push`, `web`, `trigger`, `schedule`, `api`, and `pipeline`. For pipelines created before GitLab 9.5, this will show as `unknown` |
| `CI_PIPELINE_TRIGGERED` | all | all | The flag to indicate that job was [triggered] |
| `CI_PIPELINE_TRIGGERED` | all | all | The flag to indicate that job was [triggered](../triggers/README.md) |
| `CI_PIPELINE_URL` | 11.1 | 0.5 | Pipeline details URL |
| `CI_PROJECT_DIR` | all | all | The full path where the repository is cloned and where the job is run. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see [Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) for GitLab Runner. |
| `CI_PROJECT_ID` | all | all | The unique id of the current project that GitLab CI uses internally |
......
# Adding a system message to every page
> [Introduced][ee-1283] in [GitLab Premium][eep] 10.7.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
> [Added](https://gitlab.com/gitlab-org/gitlab-ce/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
Navigate to the **Admin** area and go to the **Appearance** page.
......
......@@ -560,7 +560,7 @@ NOTE: **Note:**
If you want to use HTTPS, see [Using HTTPS](#using-https) for the additional steps.
NOTE: **Note:**
Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1 hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check will fail with "Check GitLab API access: FAILED. code: 401" and pushing commits will be rejected with "[remote rejected] master -> master (hook declined)".
Make sure your hostname can be resolved on the machine itself by either a proper DNS record or an additional line in `/etc/hosts` ("127.0.0.1 hostname"). This might be necessary, for example, if you set up GitLab behind a reverse proxy. If the hostname cannot be resolved, the final installation check will fail with `Check GitLab API access: FAILED. code: 401` and pushing commits will be rejected with `[remote rejected] master -> master (hook declined)`.
NOTE: **Note:**
GitLab Shell application startup time can be greatly reduced by disabling RubyGems. This can be done in several ways:
......
......@@ -167,7 +167,7 @@ To disable the Elasticsearch integration:
1. Find the 'Elasticsearch' section and uncheck 'Search with Elasticsearch enabled'
and 'Elasticsearch indexing'
1. Click **Save** for the changes to take effect
1. [Optional] Delete the existing index by running the command `sudo gitlab-rake gitlab:elastic:delete_index`
1. (Optional) Delete the existing index by running the command `sudo gitlab-rake gitlab:elastic:delete_index`
## Adding GitLab's data to the Elasticsearch index
......
......@@ -111,7 +111,7 @@ file.
[Ingress](https://kubernetes.github.io/ingress-nginx/) can provide load
balancing, SSL termination, and name-based virtual hosting. It acts as a
web proxy for your applications and is useful if you want to use [Auto
DevOps] or deploy your own web apps.
DevOps](../../topics/autodevops/index.md) or deploy your own web apps.
NOTE: **Note:**
The
......
......@@ -288,7 +288,7 @@ $example = array(
> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#inline-diff).
With inline diff tags you can display {+ additions +} or [- deletions -].
With inline diff tags you can display `{+ additions +}` or `[- deletions -]`.
The wrapping tags can be either curly braces or square brackets:
......
......@@ -122,8 +122,8 @@ The following table depicts the various user permission levels in a project.
| Transfer project to another namespace | | | | | ✓ |
| Remove project | | | | | ✓ |
| Delete issues | | | | | ✓ |
| Force push to protected branches [^4] | | | | | |
| Remove protected branches [^4] | | | | | |
| Force push to protected branches (*4*) | | | | | |
| Remove protected branches (*4*) | | | | | |
- (*1*): All users are able to perform this action on public and internal projects, but not private projects.
- (*2*): Guest users can only view the confidential issues they created themselves
......
......@@ -44,7 +44,7 @@ Canary deployments require that you properly configure Deploy Boards:
1. Follow the steps to [enable Deploy Boards](deploy_boards.md#enabling-deploy-boards).
1. To track canary deployments you need to label your Kubernetes deployments and
pods with `track: canary`. To get started quickly, you can use the [Auto Deploy]
pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../ci/autodeploy/index.md)
template for canary deployments that GitLab provides.
Depending on the deploy, the label should be either `stable` or `canary`.
......@@ -62,7 +62,6 @@ can easily notice them.
![Canary deployments on Deploy Board](img/deploy_boards_canary_deployments.png)
[autodeploy]: ../../ci/autodeploy/index.md "GitLab Autodeploy"
[eep]: https://about.gitlab.com/pricing/
[ee-1659]: https://gitlab.com/gitlab-org/gitlab-ee/issues/1659
[kube-canary]: https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments
......
......@@ -11,8 +11,8 @@ The [Prometheus service](../prometheus.md) must be enabled.
| Name | Query |
| ---- | ----- |
| Throughput (req/sec) | sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m])) by (code) |
| HTTP Error Rate (%) | sum(rate(haproxy_frontend_http_requests_total{code="5xx",%{environment_filter}}[2m])) / sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m])) |
| Throughput (req/sec) | `sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m])) by (code)` |
| HTTP Error Rate (%) | `sum(rate(haproxy_frontend_http_requests_total{code="5xx",%{environment_filter}}[2m])) / sum(rate(haproxy_frontend_http_requests_total{%{environment_filter}}[2m]))` |
## Configuring Prometheus to monitor for HAProxy metrics
......
......@@ -14,9 +14,9 @@ NGINX server metrics are detected, which tracks the pages and content directly s
| Name | Query |
| ---- | ----- |
| Throughput (req/sec) | sum(rate(nginx_server_requests{server_zone!="*", server_zone!="_", %{environment_filter}}[2m])) by (code) |
| Latency (ms) | avg(nginx_server_requestMsec{%{environment_filter}}) |
| HTTP Error Rate (HTTP Errors / sec) | sum(rate(nginx_server_requests{code="5xx", %{environment_filter}}[2m])) |
| Throughput (req/sec) | `sum(rate(nginx_server_requests{server_zone!="*", server_zone!="_", %{environment_filter}}[2m])) by (code)` |
| Latency (ms) | `avg(nginx_server_requestMsec{%{environment_filter}})` |
| HTTP Error Rate (HTTP Errors / sec) | `sum(rate(nginx_server_requests{code="5xx", %{environment_filter}}[2m]))` |
## Configuring Prometheus to monitor for NGINX metrics
......
......@@ -14,9 +14,9 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
| Name | Query |
| ---- | ----- |
| Throughput (req/sec) | sum(label_replace(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m]), "status_code", "${1}xx", "status", "(.)..")) by (status_code) |
| Latency (ms) | sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_sum{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_count{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 1000 |
| HTTP Error Rate (%) | sum(rate(nginx_ingress_controller_requests{status=~"5.*",namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 100 |
| Throughput (req/sec) | `sum(label_replace(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m]), "status_code", "${1}xx", "status", "(.)..")) by (status_code)` |
| Latency (ms) | `sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_sum{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_count{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 1000` |
| HTTP Error Rate (%) | `sum(rate(nginx_ingress_controller_requests{status=~"5.*",namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 100` |
## Configuring NGINX ingress monitoring
......
......@@ -14,9 +14,9 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
| Name | Query |
| ---- | ----- |
| Throughput (req/sec) | sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code) |
| Latency (ms) | avg(nginx_upstream_response_msecs_avg{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}) |
| HTTP Error Rate (%) | sum(rate(nginx_upstream_responses_total{status_code="5xx", upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) / sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) * 100 |
| Throughput (req/sec) | `sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) by (status_code)` |
| Latency (ms) | `avg(nginx_upstream_response_msecs_avg{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"})` |
| HTTP Error Rate (%) | `sum(rate(nginx_upstream_responses_total{status_code="5xx", upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) / sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) * 100` |
## Configuring NGINX ingress monitoring
......
......@@ -15,7 +15,7 @@ being merged, and it will stay disabled until the "WIP" flag has been removed.
There are several ways to flag a merge request as a Work In Progress:
- Add "[WIP]" or "WIP:" to the start of the merge request's title. Clicking on
- Add `[WIP]` or `WIP:` to the start of the merge request's title. Clicking on
**Start the title with WIP:**, under the title box, when editing the merge request's
description will have the same effect.
- Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-and-merge-requests)
......@@ -30,7 +30,7 @@ There are several ways to flag a merge request as a Work In Progress:
Similar to above, when a Merge Request is ready to be merged, you can remove the
"Work in Progress" flag in several ways:
- Remove "[WIP]" or "WIP:" from the start of the merge request's title. Clicking on
- Remove `[WIP]` or `WIP:` from the start of the merge request's title. Clicking on
**Remove the WIP: prefix from the title**, under the title box, when editing the merge
request's description, will have the same effect.
- Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-and-merge-requests)
......
......@@ -175,7 +175,7 @@ A merge request is an online place to discuss the change and review the code.
If you open the merge request but do not assign it to anyone, it is a "Work In Progress" merge request.
These are used to discuss the proposed implementation but are not ready for inclusion in the `master` branch yet.
Start the title of the merge request with "[WIP]" or "WIP:" to prevent it from being merged before it's ready.
Start the title of the merge request with `[WIP]` or `WIP:` to prevent it from being merged before it's ready.
When you think the code is ready, assign the merge request to a reviewer.
The reviewer can merge the changes when they think the code is ready for inclusion in the `master` branch.
......
......@@ -65,7 +65,7 @@ These settings can be configured on project page under the name of the project.
Below is the table of events users can be notified of:
| Event | Sent to | Settings level |
|------------------------------|-------------------------------------------------------------------|------------------------------|
|------------------------------|---------------------|------------------------------|
| New SSH key added | User | Security email, always sent. |
| New email added | User | Security email, always sent. |
| Email changed | User | Security email, always sent. |
......@@ -75,7 +75,7 @@ Below is the table of events users can be notified of:
| Project access level changed | User | Sent when user project access level is changed |
| User added to group | User | Sent when user is added to group |
| Group access level changed | User | Sent when user group access level is changed |
| Project moved | Project members [1] | [1] not disabled |
| Project moved | Project members (1) | (1) not disabled |
### Issue / Epics / Merge request events
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment