Merge branch 'eread/make-more-topics-compatible-with-newer-markdownlint-cli' into 'master'

Make some documentation topics compatible with newer `markdownlint-cli`

See merge request gitlab-org/gitlab!72554

doc/development/elasticsearch.md

@@ -359,17 +359,15 @@ being upgraded to, we do the following:
 
 ### Prometheus
 
-GitLab exports [Prometheus
-metrics](../administration/monitoring/prometheus/gitlab_metrics.md) relating to
-the number of requests and timing for all web/API requests and Sidekiq jobs,
+GitLab exports [Prometheus metrics](../administration/monitoring/prometheus/gitlab_metrics.md)
+relating to the number of requests and timing for all web/API requests and Sidekiq jobs,
 which can help diagnose performance trends and compare how Elasticsearch timing
 is impacting overall performance relative to the time spent doing other things.
 
 #### Indexing queues
 
-GitLab also exports [Prometheus
-metrics](../administration/monitoring/prometheus/gitlab_metrics.md) for
-indexing queues, which can help diagnose performance bottlenecks and determine
+GitLab also exports [Prometheus metrics](../administration/monitoring/prometheus/gitlab_metrics.md)
+for indexing queues, which can help diagnose performance bottlenecks and determine
 whether or not your GitLab instance or Elasticsearch server can keep up with
 the volume of updates.
 

doc/development/go_guide/index.md

@@ -364,8 +364,7 @@ JSON format, as all our infrastructure assumes that. When using
 [Logrus](https://github.com/sirupsen/logrus) you can turn on structured
 logging simply by using the build in [JSON
 formatter](https://github.com/sirupsen/logrus#formatters). This follows the
-same logging type we use in our [Ruby
-applications](../logging.md#use-structured-json-logging).
+same logging type we use in our [Ruby applications](../logging.md#use-structured-json-logging).
 
 #### How to use Logrus
 

doc/development/internal_api.md

@@ -300,7 +300,7 @@ personal access token.
 | `scopes` | string array | yes | The authorization scopes for the new token, these must be valid token scopes |
 | `expires_at` | string | no | The expiry date for the new token |
 | `key_id`  | integer | no | The ID of the SSH key used as found in the authorized-keys file or through the `/authorized_keys` check |
-| `user_id` | integer | no | User\_id for which to generate the new token |
+| `user_id` | integer | no | User ID for which to generate the new token |
 
 ```plaintext
 POST /internal/personal_access_token

doc/development/iterating_tables_in_batches.md

@@ -142,7 +142,7 @@ database query:
 SELECT "users"."id" FROM "users" ORDER BY "users"."id" ASC LIMIT 1
 ```
 
-![Reading the start id value](img/each_batch_users_table_iteration_1_v13_7.png)
+![Reading the start `id` value](img/each_batch_users_table_iteration_1_v13_7.png)
 
 Notice that the query only reads data from the index (`INDEX ONLY SCAN`), the table is not
 accessed. Database indexes are sorted so taking out the first item is a very cheap operation.
@@ -155,7 +155,7 @@ to get a "shifted" `id` value.
 SELECT "users"."id" FROM "users" WHERE "users"."id" >= 1 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5
 ```
 
-![Reading the end id value](img/each_batch_users_table_iteration_2_v13_7.png)
+![Reading the end `id` value](img/each_batch_users_table_iteration_2_v13_7.png)
 
 Again, the query only looks into the index. The `OFFSET 5` takes out the sixth `id` value: this
 query reads a maximum of six items from the index regardless of the table size or the iteration
@@ -181,7 +181,7 @@ previous iteration in order to find out the next end `id` value.
 SELECT "users"."id" FROM "users" WHERE "users"."id" >= 302 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5
 ```
 
-![Reading the second end id value](img/each_batch_users_table_iteration_4_v13_7.png)
+![Reading the second end `id` value](img/each_batch_users_table_iteration_4_v13_7.png)
 
 Now we can easily construct the `users` query for the second iteration.
 

doc/development/redis.md

@@ -21,8 +21,7 @@ GitLab uses [Redis](https://redis.io) for the following distinct purposes:
 In most environments (including the GDK), all of these point to the same
 Redis instance.
 
-On GitLab.com, we use [separate Redis
-instances](../administration/redis/replication_and_failover.md#running-multiple-redis-clusters).
+On GitLab.com, we use [separate Redis instances](../administration/redis/replication_and_failover.md#running-multiple-redis-clusters).
 See the [Redis SRE guide](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/redis/redis-survival-guide-for-sres.md)
 for more details on our setup.
 
@@ -121,8 +120,7 @@ on GitLab.com
 
 On GitLab.com, entries from the [Redis
 slow log](https://redis.io/commands/slowlog) are available in the
-`pubsub-redis-inf-gprd*` index with the [`redis.slowlog`
-tag](https://log.gprd.gitlab.net/app/kibana#/discover?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-1d,to:now))&_a=(columns:!(json.type,json.command,json.exec_time_s),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:AWSQX_Vf93rHTYrsexmk,key:json.tag,negate:!f,params:(query:redis.slowlog),type:phrase),query:(match:(json.tag:(query:redis.slowlog,type:phrase))))),index:AWSQX_Vf93rHTYrsexmk)).
+`pubsub-redis-inf-gprd*` index with the [`redis.slowlog` tag](https://log.gprd.gitlab.net/app/kibana#/discover?_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-1d,to:now))&_a=(columns:!(json.type,json.command,json.exec_time_s),filters:!(('$state':(store:appState),meta:(alias:!n,disabled:!f,index:AWSQX_Vf93rHTYrsexmk,key:json.tag,negate:!f,params:(query:redis.slowlog),type:phrase),query:(match:(json.tag:(query:redis.slowlog,type:phrase))))),index:AWSQX_Vf93rHTYrsexmk)).
 This shows commands that have taken a long time and may be a performance
 concern.
 

doc/development/sidekiq_style_guide.md

@@ -740,8 +740,7 @@ We use the following approach to determine whether a worker is CPU-bound:
 
 ## Feature category
 
-All Sidekiq workers must define a known [feature
-category](feature_categorization/index.md#sidekiq-workers).
+All Sidekiq workers must define a known [feature category](feature_categorization/index.md#sidekiq-workers).
 
 ## Job weights
 

doc/install/installation.md

@@ -1027,7 +1027,7 @@ misconfigured GitLab Workhorse instance. Double-check that you've
 [installed Go](#3-go), [installed GitLab Workhorse](#install-gitlab-workhorse),
 and correctly [configured NGINX](#site-configuration).
 
-### `google-protobuf` "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found"
+### `google-protobuf` "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.14' not found"
 
 This can happen on some platforms for some versions of the
 `google-protobuf` gem. The workaround is to install a source-only

doc/integration/gmail_action_buttons_for_gitlab.md

@@ -10,7 +10,7 @@ GitLab supports [Google actions in email](https://developers.google.com/gmail/ma
 
 If correctly set up, emails that require an action are marked in Gmail.
 
-![GMail actions button](img/gmail_action_buttons_for_gitlab.png)
+![Gmail actions button](img/gmail_action_buttons_for_gitlab.png)
 
 To get this functioning, you must be registered with Google. For instructions, see
 [Register with Google](https://developers.google.com/gmail/markup/registering-with-google).

doc/integration/salesforce.md

@@ -79,7 +79,9 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
    ![Salesforce App Secret Details](img/salesforce_app_secret_details.png)
 
 1. Save the configuration file.
-1. [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or
+   [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes
+   to take effect if you installed GitLab via Omnibus or from source respectively.
 
 On the sign in page, there should now be a Salesforce icon below the regular sign in form.
 Click the icon to begin the authentication process. Salesforce asks the user to sign in and authorize the GitLab application.

doc/subscriptions/self_managed/index.md

@@ -181,9 +181,9 @@ The daily job provides **only** the following information to the Customers Porta
 - Instance ID
 - MD5 hash of license
 
-<details>
-<summary>Click here to view an example of a cloud licensing sync request.</summary>
-<pre><code>
+Example of a cloud licensing sync request:
+
+```json
 {
   "gitlab_version": "14.1.0-pre",
   "timestamp": "2021-06-14T12:00:09Z",
@@ -231,8 +231,7 @@ The daily job provides **only** the following information to the Customers Porta
   "instance_id": "9367590b-82ad-48cb-9da7-938134c29088",
   "license_md5": "002f02470fe45ef6a333a4282aca6222"
 }
-</code></pre>
-</details>
+```
 
 #### Sync subscription details
 

doc/topics/autodevops/multiple_clusters_auto_devops.md

@@ -35,8 +35,8 @@ To add a different cluster for each environment:
 1. Navigate to your project's **Infrastructure > Kubernetes clusters**.
 1. Create the Kubernetes clusters with their respective environment scope, as
    described from the table above.
-1. After creating the clusters, navigate to each cluster and [install
-   Ingress](quick_start_guide.md#install-ingress). Wait for the Ingress IP address to be assigned.
+1. After creating the clusters, navigate to each cluster and [install Ingress](quick_start_guide.md#install-ingress).
+   Wait for the Ingress IP address to be assigned.
 1. Make sure you've [configured your DNS](requirements.md#auto-devops-base-domain) with the
    specified Auto DevOps domains.
 1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**,

doc/update/index.md

@@ -163,12 +163,10 @@ To address the above two scenario's, it is advised to do the following prior to
 
 ## Checking for pending Advanced Search migrations
 
-This section is only applicable if you have enabled the [Elasticsearch
-integration](../integration/elasticsearch.md).
+This section is only applicable if you have enabled the [Elasticsearch integration](../integration/elasticsearch.md).
 
-Major releases require all [Advanced Search
-migrations](../integration/elasticsearch.md#advanced-search-migrations) to
-be finished from the most recent minor release in your current version
+Major releases require all [Advanced Search migrations](../integration/elasticsearch.md#advanced-search-migrations)
+to be finished from the most recent minor release in your current version
 before the major version upgrade. You can find pending migrations by
 running the following command:
 
@@ -187,8 +185,7 @@ sudo -u git -H bundle exec rake gitlab:elastic:list_pending_migrations
 
 ### What do I do if my Advanced Search migrations are stuck?
 
-See [how to retry a halted
-migration](../integration/elasticsearch.md#retry-a-halted-migration).
+See [how to retry a halted migration](../integration/elasticsearch.md#retry-a-halted-migration).
 
 ## Upgrade paths
 
@@ -234,12 +231,11 @@ It's also important to ensure that any background migrations have been fully com
 before upgrading to a new major version. To see the current size of the `background_migration` queue,
 [Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
 
-If you have enabled the [Elasticsearch
-integration](../integration/elasticsearch.md), then ensure
+If you have enabled the [Elasticsearch integration](../integration/elasticsearch.md), then ensure
 all Advanced Search migrations are completed in the last minor version within
-your current version. Be sure to [check for pending Advanced Search
-migrations](#checking-for-pending-advanced-search-migrations) before proceeding
-with the major version upgrade.
+your current version. Be sure to
+[check for pending Advanced Search migrations](#checking-for-pending-advanced-search-migrations)
+before proceeding with the major version upgrade.
 
 If your GitLab instance has any runners associated with it, it is very
 important to upgrade GitLab Runner to match the GitLab minor version that was

doc/user/infrastructure/iac/mr_integration.md

@@ -77,8 +77,7 @@ To manually configure a GitLab Terraform Report artifact:
          terraform: $PLAN_JSON
    ```
 
-   For a full example using the pre-built image, see [Example `.gitlab-ci.yml`
-   file](#example-gitlab-ciyml-file).
+   For a full example using the pre-built image, see [Example `.gitlab-ci.yml` file](#example-gitlab-ciyml-file).
 
    For an example displaying multiple reports, see [`.gitlab-ci.yml` multiple reports file](#multiple-terraform-plan-reports).
 

doc/user/project/clusters/serverless/aws.md

@@ -434,11 +434,11 @@ To test the application you deployed, please go to the build log and follow the
 
 1. Click on "Show complete raw" on the upper right-hand corner:
 
-   ![sam-complete-raw](img/sam-complete-raw.png)
+   ![SAM complete raw](img/sam-complete-raw.png)
 
 1. Look for HelloWorldApi – API Gateway endpoint similar to shown below:
 
-   ![sam-api-endpoint](img/sam-api-endpoint.png)
+   ![SAM API endpoint](img/sam-api-endpoint.png)
 
 1. Use curl to test the API. For example:
 

doc/user/project/merge_requests/code_quality.md

@@ -343,8 +343,7 @@ It's possible to have a custom tool provide Code Quality reports in GitLab. To
 do this:
 
 1. Define a job in your `.gitlab-ci.yml` file that generates the
-   [Code Quality report
-   artifact](../../../ci/yaml/index.md#artifactsreportscodequality).
+   [Code Quality report artifact](../../../ci/yaml/index.md#artifactsreportscodequality).
 1. Configure your tool to generate the Code Quality report artifact as a JSON
    file that implements a subset of the [Code Climate
    spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).

doc/user/project/pages/getting_started/pages_ci_cd_template.md

@@ -34,8 +34,7 @@ configuration for the Pages site to generate properly.
    If you don't find a corresponding template, you can view the
    [GitLab Pages group of sample projects](https://gitlab.com/pages).
    These projects contain `.gitlab-ci.yml` files that you can modify for your needs.
-   You can also [learn how to write your own `.gitlab-ci.yml`
-   file for GitLab Pages](pages_from_scratch.md).
+   You can also [learn how to write your own `.gitlab-ci.yml` file for GitLab Pages](pages_from_scratch.md).
 
 1. Save and commit the `.gitlab-ci.yml` file.
 

doc/user/search/index.md

@@ -118,7 +118,7 @@ You can add this URL to your feed reader.
 
 You can filter the **Issues** list to individual instances by their ID. For example, enter filter `#10` to return only issue 10. The same applies to the **Merge Requests** list. Enter filter `#30` to return only merge request 30.
 
-![filter issues by specific id](img/issue_search_by_id.png)
+![filter issues by specific ID](img/issue_search_by_id.png)
 
 ### Filtering merge requests by approvers **(PREMIUM)**