Add language declarations to code blocks

Adding more language declarations to code blocks.

doc/administration/troubleshooting/debug.md

@@ -33,7 +33,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
 
    ```ruby
    irb(main):002:0> ActionMailer::Base.smtp_settings
-   => {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}```
+   => {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}
    ```
 
    In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
@@ -56,13 +56,13 @@ For more advanced issues, `gdb` is a must-have tool for debugging issues.
 
 To install on Ubuntu/Debian:
 
-```
+```shell
 sudo apt-get install gdb
 ```
 
 On CentOS:
 
-```
+```shell
 sudo yum install gdb
 ```
 
@@ -103,14 +103,14 @@ downtime. Otherwise skip to the next section.
 1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
 1. In the gdb window, type:
 
-   ```
+   ```plaintext
    call (void) rb_backtrace()
    ```
 
 1. This forces the process to generate a Ruby backtrace. Check
    `/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtace. For example, you may see:
 
-   ```ruby
+   ```plaintext
    from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
    from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
    from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
@@ -124,13 +124,13 @@ downtime. Otherwise skip to the next section.
 
 1. To see the current threads, run:
 
-   ```
+   ```plaintext
    thread apply all bt
    ```
 
 1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
 
-   ```
+   ```plaintext
    detach
    exit
    ```
@@ -162,7 +162,7 @@ separate Rails process to debug the issue:
 1. Create a Personal Access Token for your user (Profile Settings -> Access Tokens).
 1. Bring up the GitLab Rails console. For omnibus users, run:
 
-   ```
+   ```shell
    sudo gitlab-rails console
    ```
 

doc/administration/troubleshooting/postgresql.md

@@ -99,13 +99,13 @@ References:
 - [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [Google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
 - [Issue #2 deadlocks can occur if an instance is flooded with pushes](https://gitlab.com/gitlab-org/gitlab/issues/33650). Provided for context about how GitLab code can have this sort of unanticipated effect in unusual situations.
 
-```
+```plaintext
 ERROR: deadlock detected
 ```
 
 Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528); our recommended settings are as follows:
 
-```
+```ini
 deadlock_timeout = 5s
 statement_timeout = 15s
 idle_in_transaction_session_timeout = 60s
@@ -128,7 +128,7 @@ Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indica
 
 See current settings with:
 
-```
+```shell
 sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
 puts c.execute('SHOW lock_timeout').to_a ;
 puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"

doc/administration/troubleshooting/sidekiq.md

@@ -31,7 +31,7 @@ Check in `/var/log/gitlab/sidekiq/current` or `$GITLAB_HOME/log/sidekiq.log` for
 the backtrace output. The backtraces will be lengthy and generally start with
 several `WARN` level messages. Here's an example of a single thread's backtrace:
 
-```
+```plaintext
 2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: ActiveRecord::RecordNotFound: Couldn't find Note with 'id'=3375386
 2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.2.5.2/lib/active_record/core.rb:155:in `find'
 /opt/gitlab/embedded/service/gitlab-rails/app/workers/new_note_worker.rb:7:in `perform'
@@ -55,7 +55,7 @@ respond to the `TTIN` signal, this is a good next step.
 
 If `perf` is not installed on your system, install it with `apt-get` or `yum`:
 
-```
+```shell
 # Debian
 sudo apt-get install linux-tools
 
@@ -68,13 +68,13 @@ sudo yum install perf
 
 Run perf against the Sidekiq PID:
 
-```
+```shell
 sudo perf record -p <sidekiq_pid>
 ```
 
 Let this run for 30-60 seconds and then press Ctrl-C. Then view the perf report:
 
-```
+```shell
 sudo perf report
 
 # Sample output
@@ -102,13 +102,13 @@ of the process (Sidekiq will not process jobs while `gdb` is attached).
 
 Start by attaching to the Sidekiq PID:
 
-```
+```shell
 gdb -p <sidekiq_pid>
 ```
 
 Then gather information on all the threads:
 
-```
+```plaintext
 info threads
 
 # Example output
@@ -129,7 +129,7 @@ from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokog
 If you see a suspicious thread, like the Nokogiri one above, you may want
 to get more information:
 
-```
+```plaintext
 thread 21
 bt
 
@@ -147,7 +147,7 @@ bt
 
 To output a backtrace from all threads at once:
 
-```
+```plaintext
 set pagination off
 thread apply all bt
 ```
@@ -155,7 +155,7 @@ thread apply all bt
 Once you're done debugging with `gdb`, be sure to detach from the process and
 exit:
 
-```
+```plaintext
 detach
 exit
 ```

doc/administration/uploads.md

@@ -153,7 +153,7 @@ Note that Oracle Cloud S3 must be sure to use the following settings:
 If `enable_signature_v4_streaming` is set to `true`, you may see the
 following error:
 
-```
+```plaintext
 STREAMING-AWS4-HMAC-SHA256-PAYLOAD is not supported
 ```
 

doc/api/admin_sidekiq_queues.md

@@ -17,7 +17,7 @@ The response has three fields:
 
 This API endpoint is only available to admin users.
 
-```
+```plaintext
 DELETE /admin/sidekiq/queues/:queue_name
 ```
 

doc/api/oauth2.md

@@ -49,7 +49,7 @@ The web application flow is:
 1. Request authorization code. To do that, you should redirect the user to the
    `/oauth/authorize` endpoint with the following GET parameters:
 
-   ```
+   ```plaintext
    https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=YOUR_UNIQUE_STATE_HASH&scope=REQUESTED_SCOPES
    ```
 
@@ -60,7 +60,7 @@ The web application flow is:
    would request `read_user` and `profile` scopes). The redirect will
    include the GET `code` parameter, for example:
 
-   ```
+   ```plaintext
    http://myapp.com/oauth/redirect?code=1234567890&state=YOUR_UNIQUE_STATE_HASH
    ```
 

doc/development/api_graphql_styleguide.md

@@ -123,7 +123,7 @@ pagination models.
 
 To expose a collection of resources we can use a connection type. This wraps the array with default pagination fields. For example a query for project-pipelines could look like this:
 
-```
+```graphql
 query($project_path: ID!) {
   project(fullPath: $project_path) {
     pipelines(first: 2) {
@@ -181,7 +181,7 @@ look like this:
 To get the next page, the cursor of the last known element could be
 passed:
 
-```
+```graphql
 query($project_path: ID!) {
   project(fullPath: $project_path) {
     pipelines(first: 2, after: "Njc=") {
@@ -319,7 +319,6 @@ module Types
     value 'CLOSED', value: 'closed', description: 'An closed Epic'
   end
 end
-
 ```
 
 ## Descriptions

doc/development/architecture.md

@@ -542,28 +542,28 @@ See the README for more information.
 
 The GitLab init script starts and stops Unicorn and Sidekiq:
 
-```
+```plaintext
 /etc/init.d/gitlab
 Usage: service gitlab {start|stop|restart|reload|status}
 ```
 
 Redis (key-value store/non-persistent database):
 
-```
+```plaintext
 /etc/init.d/redis
 Usage: /etc/init.d/redis {start|stop|status|restart|condrestart|try-restart}
 ```
 
 SSH daemon:
 
-```
+```plaintext
 /etc/init.d/sshd
 Usage: /etc/init.d/sshd {start|stop|restart|reload|force-reload|condrestart|try-restart|status}
 ```
 
 Web server (one of the following):
 
-```
+```plaintext
 /etc/init.d/httpd
 Usage: httpd {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}
 
@@ -573,7 +573,7 @@ Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}
 
 Persistent database:
 
-```
+```plaintext
 $ /etc/init.d/postgresql
 Usage: /etc/init.d/postgresql {start|stop|restart|reload|force-reload|status} [version ..]
 ```
@@ -626,7 +626,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
 [GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
 In a nutshell, do the following:
 
-```
+```shell
 sudo -i -u git
 cd gitlab
 bundle exec rake gitlab:env:info RAILS_ENV=production

doc/development/chaos_endpoints.md

@@ -47,7 +47,7 @@ To simulate a memory leak in your application, use the `/-/chaos/leakmem` endpoi
 NOTE: **Note:**
 The memory is not retained after the request finishes. Once the request has completed, the Ruby garbage collector will attempt to recover the memory.
 
-```
+```plaintext
 GET /-/chaos/leakmem
 GET /-/chaos/leakmem?memory_mb=1024
 GET /-/chaos/leakmem?memory_mb=1024&duration_s=50
@@ -72,7 +72,7 @@ This endpoint attempts to fully utilise a single core, at 100%, for the given pe
 Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
 If you're using Unicorn, this is done by killing the worker process.
 
-```
+```plaintext
 GET /-/chaos/cpu_spin
 GET /-/chaos/cpu_spin?duration_s=50
 GET /-/chaos/cpu_spin?duration_s=50&async=true
@@ -96,7 +96,7 @@ This endpoint can be used to model yielding execution to another threads when ru
 Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
 If you're using Unicorn, this is done by killing the worker process.
 
-```
+```plaintext
 GET /-/chaos/db_spin
 GET /-/chaos/db_spin?duration_s=50
 GET /-/chaos/db_spin?duration_s=50&async=true
@@ -119,7 +119,7 @@ This endpoint is similar to the CPU Spin endpoint but simulates off-processor ac
 
 As with the CPU Spin endpoint, this may lead to your request timing out if duration_s exceeds the configured limit.
 
-```
+```plaintext
 GET /-/chaos/sleep
 GET /-/chaos/sleep?duration_s=50
 GET /-/chaos/sleep?duration_s=50&async=true
@@ -142,7 +142,7 @@ This endpoint will simulate the unexpected death of a worker process using a `ki
 NOTE: **Note:**
 Since this endpoint uses the `KILL` signal, the worker is not given a chance to cleanup or shutdown.
 
-```
+```plaintext
 GET /-/chaos/kill
 GET /-/chaos/kill?async=true
 ```

doc/development/database_debugging.md

@@ -39,7 +39,7 @@ If your test DB is giving you problems, it is safe to nuke it because it doesn't
 
 Access the database via one of these commands (they all get you to the same place)
 
-```
+```ruby
 gdk psql -d gitlabhq_development
 bundle exec rails dbconsole RAILS_ENV=development
 bundle exec rails db RAILS_ENV=development

doc/development/db_dump.md

@@ -10,7 +10,7 @@ data leaks.
 On the staging VM, add the following line to `/etc/gitlab/gitlab.rb` to speed up
 large database imports.
 
-```
+```shell
 # On STAGING
 echo "postgresql['checkpoint_segments'] = 64" | sudo tee -a /etc/gitlab/gitlab.rb
 sudo touch /etc/gitlab/skip-auto-reconfigure
@@ -23,7 +23,7 @@ Next, we let the production environment stream a compressed SQL dump to our
 local machine via SSH, and redirect this stream to a psql client on the staging
 VM.
 
-```
+```shell
 # On LOCAL MACHINE
 ssh -C gitlab.example.com sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -Cc gitlabhq_production |\
   ssh -C staging-vm sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -d template1
@@ -37,14 +37,14 @@ use this procedure.
 First, on the production server, create a list of directories you want to
 re-create.
 
-```
+```shell
 # On PRODUCTION
 (umask 077; sudo find /var/opt/gitlab/git-data/repositories -maxdepth 1 -type d -print0 > directories.txt)
 ```
 
 Copy `directories.txt` to the staging server and create the directories there.
 
-```
+```shell
 # On STAGING
 sudo -u git xargs -0 mkdir -p < directories.txt
 ```