Fix markdown to reduce number of kramdown warnings

Add backticks around square brackets, or fix links, as necessary.

doc/administration/auth/ldap.md

-[//]: # (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
 

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -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

doc/administration/high_availability/redis.md

@@ -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/>.
 
 ---

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -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:
 

doc/ci/variables/predefined_variables.md

@@ -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 |

doc/customization/system_header_and_footer_messages.md

 # 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.
 

doc/install/installation.md

@@ -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:

doc/integration/elasticsearch.md

@@ -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
 

doc/user/clusters/applications.md

@@ -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

doc/user/markdown.md

@@ -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:
 

doc/user/permissions.md

@@ -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

doc/user/project/canary_deployments.md

@@ -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

doc/user/project/integrations/prometheus_library/haproxy.md

@@ -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
 

doc/user/project/integrations/prometheus_library/nginx.md

@@ -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
 

doc/user/project/integrations/prometheus_library/nginx_ingress.md

@@ -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
 

doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md

@@ -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
 

doc/user/project/merge_requests/work_in_progress_merge_requests.md

@@ -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)

doc/workflow/gitlab_flow.md

@@ -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.

doc/workflow/notifications.md

@@ -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