Commit 9d8fd449 authored by Amy Qualls's avatar Amy Qualls Committed by Marcel Amirault

Add language declarations to code blocks

Add language declarations to code blocks for compliance with a
future Markdownlint rule
parent e205d28f
......@@ -115,7 +115,7 @@ also running Unicorn/Puma and/or Sidekiq.
Example output:
```
```plaintext
Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
......@@ -465,7 +465,7 @@ For installations from source:
Note: This option only works for remote storage. If you want to group your backups
you can pass a `DIRECTORY` environment variable:
```
```shell
sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly
```
......@@ -586,7 +586,7 @@ crontab -e
There, add the following line to schedule the backup for everyday at 2 AM:
```
```plaintext
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
```
......@@ -614,7 +614,7 @@ sudo -u git crontab -e # Edit the crontab for the git user
Add the following lines at the bottom:
```
```plaintext
# Create a full backup of the GitLab repositories and SQL database every day at 4am
0 4 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
```
......@@ -674,7 +674,7 @@ Read more on [configuring NFS mounts](../administration/high_availability/nfs.md
### Restore for installation from source
```
```shell
# Stop processes that are connected to the database
sudo service gitlab stop
......@@ -683,7 +683,7 @@ bundle exec rake gitlab:backup:restore RAILS_ENV=production
Example output:
```
```plaintext
Unpacking backup... [DONE]
Restoring database tables:
-- create_table("events", {:force=>true})
......@@ -853,7 +853,7 @@ will have all your repositories, but not any other data.
If you are using backup restore procedures you might encounter the following warnings:
```
```plaintext
psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR: must be owner of extension plpgsql
psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING: no privileges could be revoked for "public" (two occurrences)
psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING: no privileges were granted for "public" (two occurrences)
......@@ -1003,7 +1003,7 @@ GitLab instance after restoring the registry data.
These failures will mention permission issues in the registry logs, like:
```
```plaintext
level=error
msg="response completed with error"
err.code=unknown
......
......@@ -6,7 +6,7 @@ Clean up local project upload files if they don't exist in GitLab database. The
task attempts to fix the file if it can find its project, otherwise it moves the
file to a lost and found directory.
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:project_uploads
......@@ -16,8 +16,9 @@ bundle exec rake gitlab:cleanup:project_uploads RAILS_ENV=production
Example output:
```
```shell
$ sudo gitlab-rake gitlab:cleanup:project_uploads
I, [2018-07-27T12:08:27.671559 #89817] INFO -- : Looking for orphaned project uploads to clean up. Dry run...
D, [2018-07-27T12:08:28.293568 #89817] DEBUG -- : Processing batch of 500 project upload file paths, starting with /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out
I, [2018-07-27T12:08:28.689869 #89817] INFO -- : Can move to lost and found /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out -> /opt/gitlab/embedded/service/gitlab-rails/public/uploads/-/project-lost-found/test.out
......@@ -35,7 +36,7 @@ I, [2018-07-27T12:08:33.760257 #89817] INFO -- : Did move to lost and found /op
Remove object store upload files if they don't exist in GitLab database.
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:remote_upload_files
......@@ -45,7 +46,7 @@ bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
Example output:
```
```shell
$ sudo gitlab-rake gitlab:cleanup:remote_upload_files
I, [2018-08-02T10:26:13.995978 #45011] INFO -- : Looking for orphaned remote uploads to remove. Dry run...
......@@ -54,7 +55,7 @@ I, [2018-08-02T10:26:14.120482 #45011] INFO -- : Can be moved to lost and found
I, [2018-08-02T10:26:14.120634 #45011] INFO -- : To cleanup these files run this command with DRY_RUN=false
```
```
```shell
$ sudo gitlab-rake gitlab:cleanup:remote_upload_files DRY_RUN=false
I, [2018-08-02T10:26:47.598424 #45087] INFO -- : Looking for orphaned remote uploads to remove...
......@@ -109,7 +110,7 @@ level with `NICENESS`. Below are the valid levels, but consult
## Remove expired ActiveSession lookup keys
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys
......
......@@ -15,6 +15,6 @@ Old path: `git@example.org:myrepo.git`
New path: `git@example.org:username/myrepo.git` or `git@example.org:groupname/myrepo.git`
```
```shell
bundle exec rake gitlab:enable_namespaces RAILS_ENV=production
```
......@@ -11,6 +11,6 @@ which loads the appropriate data set if it is present within the `sample_metrics
**Example:**
```
```shell
bundle exec rake gitlab:generate_sample_prometheus_data[21]
```
......@@ -15,7 +15,7 @@
The new folder needs to have Git user ownership and read/write/execute access for Git user and its group:
```
```shell
sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
```
......@@ -27,7 +27,7 @@ sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
If we copy the repos to `/var/opt/gitlab/git-data/repository-import-<date>`, and repo A needs to be under the groups G1 and G2, it will
have to be created under those folders: `/var/opt/gitlab/git-data/repository-import-<date>/G1/G2/A.git`.
```
```shell
sudo cp -r /old/git/foo.git /var/opt/gitlab/git-data/repository-import-<date>/new_group/
# Do this once when you are done copying git repositories
......@@ -57,7 +57,7 @@ sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/re
#### Example output
```
```plaintext
Processing /var/opt/gitlab/git-data/repository-import-1/a/b/c/blah.git
* Using namespace: a/b/c
* Created blah (a/b/c/blah)
......
......@@ -3,7 +3,7 @@
You can print a list of all Git repositories on disk managed by
GitLab with the following command:
```
```shell
# Omnibus
sudo gitlab-rake gitlab:list_repos
......@@ -17,7 +17,7 @@ a date with the 'SINCE' environment variable. The time you specify
is parsed by the Rails [TimeZone#parse
function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
```
```shell
# Omnibus
sudo gitlab-rake gitlab:list_repos SINCE='Sep 1 2015'
......
......@@ -91,7 +91,7 @@ production:
Next, generate a new secret:
```
```shell
# omnibus-gitlab
sudo gitlab-rake secret
......@@ -102,7 +102,7 @@ bundle exec rake secret RAILS_ENV=production
Now you need to stop the GitLab server, back up the existing secrets file and
update the database:
```
```shell
# omnibus-gitlab
sudo gitlab-ctl stop
sudo cp config/secrets.yml config/secrets.yml.bak
......@@ -122,7 +122,7 @@ error.
Finally, change `config/secrets.yml` to set `otp_key_base` to `<new key>` and
restart. Again, make sure you're operating in the **production** section.
```
```shell
# omnibus-gitlab
sudo gitlab-ctl start
......@@ -133,7 +133,7 @@ sudo /etc/init.d/gitlab start
If there are any problems (perhaps using the wrong value for `old_key`), you can
restore your backup of `config/secrets.yml` and rollback the changes:
```
```shell
# omnibus-gitlab
sudo gitlab-ctl stop
sudo gitlab-rake gitlab:two_factor:rotate_key:rollback filename=backup.csv
......
......@@ -33,7 +33,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression
The Nessus scanner, [reports a possible CRIME vulnerability][nessus] in GitLab
similar to the following format:
```
```plaintext
Description
This remote service has one of two configurations that are known to be required for the CRIME attack:
......
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