Merge branch 'docs-capitalization-12' into 'master'

Improve caps and backticks in various admin docs

See merge request gitlab-org/gitlab!17863

doc/administration/index.md

@@ -193,7 +193,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Debugging tips](troubleshooting/debug.md): Tips to debug problems when things go wrong
 - [Log system](logs.md): Where to look for logs.
 - [Sidekiq Troubleshooting](troubleshooting/sidekiq.md): Debug when Sidekiq appears hung and is not processing jobs.
-- [Troubleshooting ElasticSearch](troubleshooting/elasticsearch.md)
+- [Troubleshooting Elasticsearch](troubleshooting/elasticsearch.md)
 
 ### Support Team Docs
 
@@ -213,7 +213,7 @@ who are aware of the risks.
 - [Useful Linux commands](troubleshooting/linux_cheat_sheet.md)
 - [Troubleshooting Kubernetes](troubleshooting/kubernetes_cheat_sheet.md)
 - [Guide to test environments](troubleshooting/test_environments.md) (for Support Engineers)
-- [GitLab rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
+- [GitLab Rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
 - Useful links:
   - [GitLab Developer Docs](../development/README.md)
   - [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html)

doc/administration/job_artifacts.md

@@ -118,7 +118,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 | `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
 | `region` | AWS region | us-east-1 |
 | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
-| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
+| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
 | `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
 | `use_iam_profile` | Set to true to use IAM profile instead of access keys | false
 

doc/administration/pages/index.md

@@ -115,7 +115,7 @@ since that is needed in all configurations.
 URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. Nginx will proxy all requests to the daemon.
+other setups as described below. NGINX will proxy all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
@@ -139,7 +139,7 @@ Watch the [video tutorial][video-admin] for this configuration.
 
 URL scheme: `https://page.example.io`
 
-Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Place the certificate and key inside `/etc/gitlab/ssl`
@@ -196,7 +196,7 @@ you have IPv6 as well as IPv4 addresses, you can use them both.
 
 URL scheme: `http://page.example.io` and `http://domain.com`
 
-In that case, the Pages daemon is running, Nginx still proxies requests to
+In that case, the Pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains are supported, but no TLS.
 
@@ -227,7 +227,7 @@ world. Custom domains are supported, but no TLS.
 
 URL scheme: `https://page.example.io` and `https://domain.com`
 
-In that case, the Pages daemon is running, Nginx still proxies requests to
+In that case, the Pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains and TLS are supported.
 
@@ -319,7 +319,7 @@ pages:
    gitlab_pages['http_proxy'] = 'http://example:8080'
    ```
 
-1. [Reconfigure Gitlab][reconfigure] for the changes to take effect.
+1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
 
 ## Activate verbose logging for daemon
 
@@ -426,7 +426,7 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
 
 ## Security
 
-You should strongly consider running GitLab pages under a different hostname
+You should strongly consider running GitLab Pages under a different hostname
 than GitLab to prevent XSS attacks.
 
 [backup]: ../../raketasks/backup_restore.md

doc/administration/pages/source.md

@@ -93,7 +93,7 @@ since that is needed in all configurations.
 URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. Nginx will proxy all requests to the daemon.
+other setups as described below. NGINX will proxy all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Install the Pages daemon:
@@ -136,7 +136,7 @@ The Pages daemon doesn't listen to the outside world.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090"
    ```
 
-1. Copy the `gitlab-pages` Nginx configuration file:
+1. Copy the `gitlab-pages` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@@ -155,7 +155,7 @@ The Pages daemon doesn't listen to the outside world.
 
 URL scheme: `https://page.example.io`
 
-Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Install the Pages daemon:
@@ -193,7 +193,7 @@ outside world.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@@ -219,7 +219,7 @@ that without TLS certificates.
 
 URL scheme: `http://page.example.io` and `http://domain.com`
 
-In that case, the pages daemon is running, Nginx still proxies requests to
+In that case, the pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains are supported, but no TLS.
 
@@ -261,7 +261,7 @@ world. Custom domains are supported, but no TLS.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80"
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@@ -284,7 +284,7 @@ world. Custom domains are supported, but no TLS.
 
 URL scheme: `https://page.example.io` and `https://domain.com`
 
-In that case, the pages daemon is running, Nginx still proxies requests to
+In that case, the pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains and TLS are supported.
 
@@ -330,7 +330,7 @@ world. Custom domains and TLS are supported.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@@ -351,7 +351,7 @@ The following information applies only for installations from source.
 Be extra careful when setting up the domain name in the NGINX config. You must
 not remove the backslashes.
 
-If your GitLab pages domain is `example.io`, replace:
+If your GitLab Pages domain is `example.io`, replace:
 
 ```bash
 server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
@@ -401,7 +401,7 @@ Pages access control is disabled by default. To enable it:
 1. Create a new [system OAuth application](../../integration/oauth_provider.md#adding-an-application-through-the-profile).
    This should be called `GitLab Pages` and have a `Redirect URL` of
    `https://projects.example.io/auth`. It does not need to be a "trusted"
-   application, but it does need the "api" scope.
+   application, but it does need the `api` scope.
 1. Start the Pages daemon with the following additional arguments:
 
    ```shell
@@ -443,7 +443,7 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
 
 ## Security
 
-You should strongly consider running GitLab pages under a different hostname
+You should strongly consider running GitLab Pages under a different hostname
 than GitLab to prevent XSS attacks.
 
 [backup]: ../../raketasks/backup_restore.md

doc/administration/repository_storage_types.md

@@ -10,7 +10,7 @@ that can be:
 
 - Mounted to the local disk
 - Exposed as an NFS shared volume
-- Accessed via [gitaly] on its own machine.
+- Accessed via [Gitaly] on its own machine.
 
 In GitLab, this is configured in `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})`
 configuration hash. The storage layouts discussed here will apply to any shard

doc/administration/smime_signing_email.md

 # Signing outgoing email with S/MIME
 
-Notification emails sent by Gitlab can be signed with S/MIME for improved
+Notification emails sent by GitLab can be signed with S/MIME for improved
 security.
 
 > **Note:**

doc/administration/troubleshooting/debug.md

@@ -89,10 +89,10 @@ in Omnibus, run as root:
 Many of the tips to diagnose issues below apply to many different situations. We'll use one
 concrete example to illustrate what you can do to learn what is going wrong.
 
-### 502 Gateway Timeout after unicorn spins at 100% CPU
+### 502 Gateway Timeout after Unicorn spins at 100% CPU
 
 This error occurs when the Web server times out (default: 60 s) after not
-hearing back from the unicorn worker. If the CPU spins to 100% while this in
+hearing back from the Unicorn worker. If the CPU spins to 100% while this in
 progress, there may be something taking longer than it should.
 
 To fix this issue, we first need to figure out what is happening. The
@@ -100,7 +100,7 @@ following tips are only recommended if you do NOT mind users being affected by
 downtime. Otherwise skip to the next section.
 
 1. Load the problematic URL
-1. Run `sudo gdb -p <PID>` to attach to the unicorn process.
+1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
 1. In the gdb window, type:
 
    ```
@@ -135,7 +135,7 @@ downtime. Otherwise skip to the next section.
    exit
    ```
 
-Note that if the unicorn process terminates before you are able to run these
+Note that if the Unicorn process terminates before you are able to run these
 commands, gdb will report an error. To buy more time, you can always raise the
 Unicorn timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
 increase it from 60 seconds to 300:
@@ -152,7 +152,7 @@ For source installations, edit `config/unicorn.rb`.
 
 #### Troubleshooting without affecting other users
 
-The previous section attached to a running unicorn process, and this may have
+The previous section attached to a running Unicorn process, and this may have
 undesirable effects for users trying to access GitLab during this time. If you
 are concerned about affecting others during a production system, you can run a
 separate Rails process to debug the issue:
@@ -183,7 +183,7 @@ separate Rails process to debug the issue:
 
 ### GitLab: API is not accessible
 
-This often occurs when gitlab-shell attempts to request authorization via the
+This often occurs when GitLab Shell attempts to request authorization via the
 internal API (e.g., `http://localhost:8080/api/v4/internal/allowed`), and
 something in the check fails. There are many reasons why this may happen:
 
@@ -192,7 +192,7 @@ something in the check fails. There are many reasons why this may happen:
 1. Error accessing the repository (e.g., stale NFS handles)
 
 To diagnose this problem, try to reproduce the problem and then see if there
-is a unicorn worker that is spinning via `top`. Try to use the `gdb`
+is a Unicorn worker that is spinning via `top`. Try to use the `gdb`
 techniques above. In addition, using `strace` may help isolate issues:
 
 ```shell

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -4,7 +4,7 @@ type: reference
 
 # GitLab Rails Console Cheat Sheet
 
-This is the GitLab Support Team's collection of information regarding the GitLab rails
+This is the GitLab Support Team's collection of information regarding the GitLab Rails
 console, for use while troubleshooting. It is listed here for transparency,
 and it may be useful for users with experience with these tools. If you are currently
 having an issue with GitLab, it is highly recommended that you check your
@@ -822,7 +822,7 @@ License.current # check to make sure it applied
 
 From [Zendesk ticket #91083](https://gitlab.zendesk.com/agent/tickets/91083) (internal)
 
-### Poll unicorn requests by seconds
+### Poll Unicorn requests by seconds
 
 ```ruby
 require 'rubygems'
@@ -898,13 +898,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>.
 
 ## Redis
 
-### Connect to redis (omnibus)
+### Connect to Redis (omnibus)
 
 ```sh
 /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
 ```
 
-### Connect to redis (HA)
+### Connect to Redis (HA)
 
 ```sh
 /opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password>

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -15,7 +15,7 @@ If you are on a [paid tier](https://about.gitlab.com/pricing/) and are not sure
 to use these commands, it is best to [contact Support](https://about.gitlab.com/support/)
 and they will assist you with any issues you are having.
 
-## Generic kubernetes commands
+## Generic Kubernetes commands
 
 - How to authorize to your GCP project (can be especially useful if you have projects
   under different GCP accounts):
@@ -33,7 +33,7 @@ and they will assist you with any issues you are having.
   kubectl proxy
   ```
 
-- How to ssh to a Kubernetes node and enter the container as root
+- How to SSH to a Kubernetes node and enter the container as root
   <https://github.com/kubernetes/kubernetes/issues/30656>:
 
   - For GCP, you may find the node name and run `gcloud compute ssh node-name`.
@@ -72,12 +72,12 @@ and they will assist you with any issues you are having.
   This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
   for details.
 
-## GitLab-specific kubernetes information
+## GitLab-specific Kubernetes information
 
-- Minimal config that can be used to test a Kubernetes helm chart can be found
+- Minimal config that can be used to test a Kubernetes Helm chart can be found
   [here](https://gitlab.com/gitlab-org/charts/gitlab/issues/620).
 
-- Tailing logs of a separate pod. An example for a unicorn pod:
+- Tailing logs of a separate pod. An example for a Unicorn pod:
 
   ```bash
   kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
@@ -101,7 +101,7 @@ and they will assist you with any issues you are having.
   ```
 
 - Check all events in the `gitlab` namespace (the namespace name can be different if you
-  specified a different one when deploying the helm chart):
+  specified a different one when deploying the Helm chart):
 
   ```bash
   kubectl get events -w --namespace=gitlab
@@ -140,8 +140,8 @@ and they will assist you with any issues you are having.
 
   - Check the output of `kubectl get events -w --all-namespaces`.
   - Check the logs of pods within `gitlab-managed-apps` namespace.
-  - On the side of GitLab check sidekiq log and kubernetes log. When GitLab is installed
-    via Helm Chart, `kubernetes.log` can be found inside the sidekiq pod.
+  - On the side of GitLab check Sidekiq log and Kubernetes log. When GitLab is installed
+    via Helm Chart, `kubernetes.log` can be found inside the Sidekiq pod.
 
 - How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:
 

doc/administration/troubleshooting/sidekiq.md

@@ -238,7 +238,7 @@ workers.each do |process_id, thread_id, work|
 end
 ```
 
-### Remove sidekiq jobs for given parameters (destructive)
+### Remove Sidekiq jobs for given parameters (destructive)
 
 ```ruby
 # for jobs like this:

doc/administration/troubleshooting/test_environments.md

@@ -49,7 +49,7 @@ gitlab/gitlab-ee:11.5.3-ee.0
 
 #### SAML for Authentication
 
-We can use the [test-saml-idp Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
+We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
 to do the work for us:
 
 ```sh
@@ -91,7 +91,7 @@ gitlab_rails['omniauth_providers'] = [
 
 See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/saml.md).
 
-### ElasticSearch
+### Elasticsearch
 
 ```sh
 docker run -d --name elasticsearch \
@@ -101,7 +101,7 @@ docker.elastic.co/elasticsearch/elasticsearch:5.5.1
 ```
 
 Then confirm it works in the browser at `curl http://<IP_ADDRESS>:9200/_cat/health`.
-ElasticSearch's default username is `elastic` and password is `changeme`.
+Elasticsearch's default username is `elastic` and password is `changeme`.
 
 ### PlantUML
 

doc/user/gitlab_com/index.md

@@ -355,38 +355,38 @@ publicly available at [chef cookbooks](https://gitlab.com/gitlab-cookbooks).
 
 We use Elasticsearch, logstash, and Kibana for part of our monitoring solution:
 
-- [gitlab-cookbooks / gitlab-elk · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
-- [gitlab-cookbooks / gitlab_elasticsearch · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
+- [`gitlab-cookbooks` / `gitlab-elk` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
+- [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
 
 ### Prometheus
 
 Prometheus complete our monitoring stack:
 
-- [gitlab-cookbooks / gitlab-prometheus · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
+- [`gitlab-cookbooks` / `gitlab-prometheus` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
 
 ### Grafana
 
 For the visualization of monitoring data:
 
-- [gitlab-cookbooks / gitlab-grafana · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
+- [`gitlab-cookbooks` / `gitlab-grafana` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
 
 ### Sentry
 
 Open source error tracking:
 
-- [gitlab-cookbooks / gitlab-sentry · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
+- [`gitlab-cookbooks` / `gitlab-sentry` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
 
 ### Consul
 
 Service discovery:
 
-- [gitlab-cookbooks / gitlab_consul · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
+- [`gitlab-cookbooks` / `gitlab_consul` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
 
 ### Haproxy
 
 High Performance TCP/HTTP Load Balancer:
 
-- [gitlab-cookbooks / gitlab-haproxy · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
+- [`gitlab-cookbooks` / `gitlab-haproxy` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
 
 [autoscale mode]: https://docs.gitlab.com/runner/configuration/autoscale.html "How Autoscale works"
 [runners-post]: https://about.gitlab.com/2016/04/05/shared-runners/ "Shared Runners on GitLab.com"