diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2019-09-26 09:06:27 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2019-09-26 09:06:27 +0300 |
| commit | 9735395f94088df7e6470e3e8a2638385ede36b6 (patch) | |
| tree | fbd42e043d05dbc78872b0458baac3a216ea232e /doc/administration | |
| parent | 33586a7aa128171b1bbc9380648b6945b09f5e2d (diff) | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration')
19 files changed, 59 insertions, 53 deletions
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index d0c78031055..ef73b765745 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -3,7 +3,7 @@ [Gitaly](https://gitlab.com/gitlab-org/gitaly) is the service that provides high-level RPC access to Git repositories. Without it, no other components can read or write Git data. GitLab components that access Git -repositories (gitlab-rails, gitlab-shell, gitlab-workhorse, etc.) act as clients +repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients to Gitaly. End users do not have direct access to Gitaly. In the rest of this page, Gitaly server is referred to the standalone node that @@ -47,8 +47,8 @@ But since 11.8 the indexer uses Gitaly for data access as well. NFS can still be leveraged for redudancy on block level of the Git data. But only has to be mounted on the Gitaly server. -Starting with GitLab 11.8, it is possible to use ElasticSearch in conjunction with -a Gitaly setup that isn't utilising NFS. In order to use ElasticSearch in this +Starting with GitLab 11.8, it is possible to use Elasticsearch in conjunction with +a Gitaly setup that isn't utilising NFS. In order to use Elasticsearch in this scenario, the [new repository indexer](../../integration/elasticsearch.md#elasticsearch-repository-indexer-beta) needs to be enabled in your GitLab configuration. @@ -71,8 +71,8 @@ The following list depicts what the network architecture of Gitaly is: - A GitLab server can use one or more Gitaly servers. - Gitaly addresses must be specified in such a way that they resolve correctly for ALL Gitaly clients. -- Gitaly clients are: Unicorn, Sidekiq, gitlab-workhorse, - gitlab-shell, Elasticsearch Indexer, and Gitaly itself. +- Gitaly clients are: Unicorn, Sidekiq, GitLab Workhorse, + GitLab Shell, Elasticsearch Indexer, and Gitaly itself. - A Gitaly server must be able to make RPC calls **to itself** via its own `(Gitaly address, Gitaly token)` pair as specified in `/config/gitlab.yml`. - Gitaly servers must not be exposed to the public internet as Gitaly's network @@ -576,7 +576,7 @@ machine. ### 1. Monitor current authentication behavior -Use prometheus to see what the current authentication behavior of your +Use Prometheus to see what the current authentication behavior of your GitLab installation is. ``` @@ -612,7 +612,7 @@ The second step is to temporarily disable authentication on the Gitaly servers. gitaly['auth_transitioning'] = true ``` -After you have applied this, your prometheus query should return +After you have applied this, your Prometheus query should return something like this: ``` @@ -631,10 +631,10 @@ gitaly['auth_token'] = 'my new secret token' ``` Remember to apply this on both your Gitaly clients *and* servers. If you -check your prometheus query while this change is being rolled out, you +check your Prometheus query while this change is being rolled out, you will see non-zero values for the `enforced="false",status="denied"` counter. -### 4. Use prometheus to ensure there are no authentication failures +### 4. Use Prometheus to ensure there are no authentication failures After you applied the Gitaly token change everywhere, and all services involved have been restarted, you should will temporarily see a mix of @@ -658,7 +658,7 @@ gitaly['auth_transitioning'] = false ### 6. Verify that authentication is enforced again -Refresh your prometheus query. You should now see the same kind of +Refresh your Prometheus query. You should now see the same kind of result as you did in the beginning: ``` diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md index 67e1729e7fd..fe0b392c2d7 100644 --- a/doc/administration/integration/plantuml.md +++ b/doc/administration/integration/plantuml.md @@ -66,7 +66,13 @@ to the local PlantUML server `http://localhost:8080/plantuml`. To enable the redirection, add the following line in `/etc/gitlab/gitlab.rb`: ```ruby -nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n proxy_cache off; \n proxy_pass http://127.0.0.1:8080; \n}\n" +nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n proxy_cache off; \n proxy_pass http://127.0.0.1:8080/plantuml/; \n}\n" +``` + +To activate the changes, run the following command: + +```sh +sudo gitlab-ctl reconfigure ``` ## GitLab diff --git a/doc/administration/logs.md b/doc/administration/logs.md index 9ccfde58605..9263ab51dc9 100644 --- a/doc/administration/logs.md +++ b/doc/administration/logs.md @@ -233,7 +233,7 @@ This file lives in `/var/log/gitlab/gitlab-shell/gitlab-shell.log` for Omnibus GitLab packages or in `/home/git/gitlab-shell/gitlab-shell.log` for installations from source. -GitLab shell is used by GitLab for executing Git commands and provide +GitLab Shell is used by GitLab for executing Git commands and provide SSH access to Git repositories. For example: ``` @@ -241,7 +241,7 @@ I, [2015-02-13T06:17:00.671315 #9291] INFO -- : Adding project root/example.git I, [2015-02-13T06:17:00.679433 #9291] INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git. ``` -User clone/fetch activity using ssh transport appears in this log as `executing git command <gitaly-upload-pack...`. +User clone/fetch activity using SSH transport appears in this log as `executing git command <gitaly-upload-pack...`. ## `unicorn_stderr.log` @@ -252,7 +252,7 @@ installations from source. Unicorn is a high-performance forking Web server which is used for serving the GitLab application. You can look at this log if, for example, your application does not respond. This log contains all -information about the state of unicorn processes at any given time. +information about the state of Unicorn processes at any given time. ``` I, [2015-02-13T06:14:46.680381 #9047] INFO -- : Refreshing Gem list diff --git a/doc/administration/monitoring/index.md b/doc/administration/monitoring/index.md index 2b3daec42bd..80e727f6a5c 100644 --- a/doc/administration/monitoring/index.md +++ b/doc/administration/monitoring/index.md @@ -10,4 +10,4 @@ Explore our features to monitor your GitLab instance: - [GitHub imports](github_imports.md): Monitor the health and progress of GitLab's GitHub importer with various Prometheus metrics. - [Monitoring uptime](../../user/admin_area/monitoring/health_check.md): Check the server status using the health check endpoint. - [IP whitelists](ip_whitelist.md): Configure GitLab for monitoring endpoints that provide health check information when probed. -- [nginx_status](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your Nginx server status +- [`nginx_status`](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your NGINX server status diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md index d389c7c5003..323f955f598 100644 --- a/doc/administration/monitoring/performance/grafana_configuration.md +++ b/doc/administration/monitoring/performance/grafana_configuration.md @@ -32,14 +32,14 @@ in the top bar. Fill in the configuration details for the InfluxDB data source. Save and Test Connection to ensure the configuration is correct. -- **Name**: InfluxDB +- **Name**: `InfluxDB` - **Default**: Checked -- **Type**: InfluxDB 0.9.x (Even if you're using InfluxDB 0.10.x) +- **Type**: `InfluxDB 0.9.x` (Even if you're using InfluxDB 0.10.x) - **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB on a separate server) -- **Access**: proxy -- **Database**: gitlab -- **User**: admin (Or the username configured when setting up InfluxDB) +- **Access**: `proxy` +- **Database**: `gitlab` +- **User**: `admin` (Or the username configured when setting up InfluxDB) - **Password**: The password configured when you set up InfluxDB  diff --git a/doc/administration/monitoring/performance/influxdb_configuration.md b/doc/administration/monitoring/performance/influxdb_configuration.md index cf6728510fe..90a7be19f90 100644 --- a/doc/administration/monitoring/performance/influxdb_configuration.md +++ b/doc/administration/monitoring/performance/influxdb_configuration.md @@ -95,7 +95,7 @@ UDP can be done using the following settings: This does the following: 1. Enable UDP and bind it to port 8089 for all addresses. -1. Store any data received in the "gitlab" database. +1. Store any data received in the `gitlab` database. 1. Define a batch of points to be 1000 points in size and allow a maximum of 5 batches _or_ flush them automatically after 1 second. 1. Define a UDP read buffer size of 200 MB. diff --git a/doc/administration/monitoring/performance/prometheus.md b/doc/administration/monitoring/performance/prometheus.md index 2c5bab46dd9..f05a420fc19 100644 --- a/doc/administration/monitoring/performance/prometheus.md +++ b/doc/administration/monitoring/performance/prometheus.md @@ -2,4 +2,4 @@ redirect_to: '../prometheus/index.md' --- -This document was moved to [monitoring/prometheus](../prometheus/index.md). +This document was moved to [another location](../prometheus/index.md). diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md index f78a3da2107..02920293daa 100644 --- a/doc/administration/monitoring/prometheus/gitlab_metrics.md +++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md @@ -42,10 +42,10 @@ The following metrics are available: | `gitlab_transaction_cache_read_hit_count_total` | Counter | 10.2 | Counter for cache hits for Rails cache calls | controller, action | | `gitlab_transaction_cache_read_miss_count_total` | Counter | 10.2 | Counter for cache misses for Rails cache calls | controller, action | | `gitlab_transaction_duration_seconds` | Histogram | 10.2 | Duration for all transactions (gitlab_transaction_* metrics) | controller, action | -| `gitlab_transaction_event_build_found_total` | Counter | 9.4 | Counter for build found for api /jobs/request | | -| `gitlab_transaction_event_build_invalid_total` | Counter | 9.4 | Counter for build invalid due to concurrency conflict for api /jobs/request | | -| `gitlab_transaction_event_build_not_found_cached_total` | Counter | 9.4 | Counter for cached response of build not found for api /jobs/request | | -| `gitlab_transaction_event_build_not_found_total` | Counter | 9.4 | Counter for build not found for api /jobs/request | | +| `gitlab_transaction_event_build_found_total` | Counter | 9.4 | Counter for build found for API /jobs/request | | +| `gitlab_transaction_event_build_invalid_total` | Counter | 9.4 | Counter for build invalid due to concurrency conflict for API /jobs/request | | +| `gitlab_transaction_event_build_not_found_cached_total` | Counter | 9.4 | Counter for cached response of build not found for API /jobs/request | | +| `gitlab_transaction_event_build_not_found_total` | Counter | 9.4 | Counter for build not found for API /jobs/request | | | `gitlab_transaction_event_change_default_branch_total` | Counter | 9.4 | Counter when default branch is changed for any repository | | | `gitlab_transaction_event_create_repository_total` | Counter | 9.4 | Counter when any repository is created | | | `gitlab_transaction_event_etag_caching_cache_hit_total` | Counter | 9.4 | Counter for etag cache hit. | endpoint | @@ -66,10 +66,10 @@ The following metrics are available: | `gitlab_transaction_event_remove_branch_total` | Counter | 9.4 | Counter when a branch is removed for any repository | | | `gitlab_transaction_event_remove_repository_total` | Counter | 9.4 | Counter when a repository is removed | | | `gitlab_transaction_event_remove_tag_total` | Counter | 9.4 | Counter when a tag is remove for any repository | | -| `gitlab_transaction_event_sidekiq_exception_total` | Counter | 9.4 | Counter of sidekiq exceptions | | +| `gitlab_transaction_event_sidekiq_exception_total` | Counter | 9.4 | Counter of Sidekiq exceptions | | | `gitlab_transaction_event_stuck_import_jobs_total` | Counter | 9.4 | Count of stuck import jobs | projects_without_jid_count, projects_with_jid_count | -| `gitlab_transaction_event_update_build_total` | Counter | 9.4 | Counter for update build for api /jobs/request/:id | | -| `gitlab_transaction_new_redis_connections_total` | Counter | 9.4 | Counter for new redis connections | | +| `gitlab_transaction_event_update_build_total` | Counter | 9.4 | Counter for update build for API /jobs/request/:id | | +| `gitlab_transaction_new_redis_connections_total` | Counter | 9.4 | Counter for new Redis connections | | | `gitlab_transaction_queue_duration_total` | Counter | 9.4 | Duration jobs were enqueued before processing | | | `gitlab_transaction_rails_queue_duration_total` | Counter | 9.4 | Measures latency between GitLab Workhorse forwarding a request to Rails | controller, action | | `gitlab_transaction_view_duration_total` | Counter | 9.4 | Duration for views | controller, action, view | diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md index 9228ebf4fed..07905e6fa3b 100644 --- a/doc/administration/monitoring/prometheus/index.md +++ b/doc/administration/monitoring/prometheus/index.md @@ -114,7 +114,7 @@ To use an external Prometheus server: gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1'] ``` -1. To scrape nginx metrics, you'll also need to configure nginx to allow the Prometheus server +1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server IP. For example: ```ruby diff --git a/doc/administration/operations/cleaning_up_redis_sessions.md b/doc/administration/operations/cleaning_up_redis_sessions.md index c9b5ab9d290..fd469ae23e3 100644 --- a/doc/administration/operations/cleaning_up_redis_sessions.md +++ b/doc/administration/operations/cleaning_up_redis_sessions.md @@ -11,8 +11,8 @@ start building up again after you clean up. In GitLab versions prior to 7.3.0, the session keys in Redis are 16-byte hexadecimal values such as '976aa289e2189b17d7ef525a6702ace9'. Starting with GitLab 7.3.0, the keys are -prefixed with 'session:gitlab:', so they would look like -'session:gitlab:976aa289e2189b17d7ef525a6702ace9'. Below we describe how to +prefixed with `session:gitlab:`, so they would look like +`session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to remove the keys in the old format. **Note:** the instructions below must be modified in accordance with your diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md index 16424c25a98..9a38e8ddd23 100644 --- a/doc/administration/operations/fast_ssh_key_lookup.md +++ b/doc/administration/operations/fast_ssh_key_lookup.md @@ -2,7 +2,7 @@ NOTE: **Note:** This document describes a drop-in replacement for the `authorized_keys` file for normal (non-deploy key) users. Consider -using [ssh certificates](ssh_certificates.md), they are even faster, +using [SSH certificates](ssh_certificates.md), they are even faster, but are not a drop-in replacement. > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in @@ -78,7 +78,7 @@ CAUTION: **Caution:** Do not disable writes until SSH is confirmed to be working perfectly, because the file will quickly become out-of-date. In the case of lookup failures (which are common), the `authorized_keys` -file will still be scanned. So git SSH performance will still be slow for many +file will still be scanned. So Git SSH performance will still be slow for many users as long as a large file exists. You can disable any more writes to the `authorized_keys` file by unchecking diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md index ec11a92db1b..d54ffacd281 100644 --- a/doc/administration/operations/moving_repositories.md +++ b/doc/administration/operations/moving_repositories.md @@ -31,7 +31,7 @@ If you want to see progress, replace `-xf` with `-xvf`. ### Tar pipe to another server You can also use a tar pipe to copy data to another server. If your -'git' user has SSH access to the newserver as 'git@newserver', you +`git` user has SSH access to the newserver as `git@newserver`, you can pipe the data through SSH. ``` @@ -61,7 +61,7 @@ If you want to see progress, replace `-a` with `-av`. ### Single rsync to another server -If the 'git' user on your source system has SSH access to the target +If the `git` user on your source system has SSH access to the target server you can send the repositories over the network with rsync. ``` @@ -95,7 +95,7 @@ after switching to the new repository storage directory. This will sync repositories with 10 rsync processes at a time. We keep track of progress so that the transfer can be restarted if necessary. -First we create a new directory, owned by 'git', to hold transfer +First we create a new directory, owned by `git`, to hold transfer logs. We assume the directory is empty before we start the transfer procedure, and that we are the only ones writing files in it. diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md index 509bc77a8c3..79e9fb778b6 100644 --- a/doc/administration/operations/sidekiq_memory_killer.md +++ b/doc/administration/operations/sidekiq_memory_killer.md @@ -2,7 +2,7 @@ The GitLab Rails application code suffers from memory leaks. For web requests this problem is made manageable using -[unicorn-worker-killer](https://github.com/kzk/unicorn-worker-killer) which +[`unicorn-worker-killer`](https://github.com/kzk/unicorn-worker-killer) which restarts Unicorn worker processes in between requests when needed. The Sidekiq MemoryKiller applies the same approach to the Sidekiq processes used by GitLab to process background jobs. @@ -10,8 +10,8 @@ to process background jobs. Unlike unicorn-worker-killer, which is enabled by default for all GitLab installations since GitLab 6.4, the Sidekiq MemoryKiller is enabled by default _only_ for Omnibus packages. The reason for this is that the MemoryKiller -relies on Runit to restart Sidekiq after a memory-induced shutdown and GitLab -installations from source do not all use Runit or an equivalent. +relies on runit to restart Sidekiq after a memory-induced shutdown and GitLab +installations from source do not all use runit or an equivalent. With the default settings, the MemoryKiller will cause a Sidekiq restart no more often than once every 15 minutes, with the restart causing about one @@ -49,7 +49,7 @@ The MemoryKiller is controlled using environment variables. the restart will be aborted. The default value for Omnibus packages is set - [in the omnibus-gitlab + [in the Omnibus GitLab repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb). - `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`: is used by _daemon_ mode. If the Sidekiq @@ -72,4 +72,4 @@ The MemoryKiller is controlled using environment variables. If the process hard shutdown/restart is not performed by Sidekiq, the Sidekiq process will be forcefully terminated after `Sidekiq.options[:timeout] * 2` seconds. An external supervision mechanism - (e.g. Runit) must restart Sidekiq afterwards. + (e.g. runit) must restart Sidekiq afterwards. diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md index 3792bcd3bca..2a9a4cff34e 100644 --- a/doc/administration/operations/ssh_certificates.md +++ b/doc/administration/operations/ssh_certificates.md @@ -3,7 +3,7 @@ > [Available in](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/19911) GitLab > Community Edition 11.2. -GitLab's default SSH authentication requires users to upload their ssh +GitLab's default SSH authentication requires users to upload their SSH public keys before they can use the SSH transport. In centralized (e.g. corporate) environments this can be a hassle diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md index 8178cb243f3..969f1211643 100644 --- a/doc/administration/operations/unicorn.md +++ b/doc/administration/operations/unicorn.md @@ -40,7 +40,7 @@ master process has PID 56227 below. The main tunables for Unicorn are the number of worker processes and the request timeout after which the Unicorn master terminates a worker process. -See the [omnibus-gitlab Unicorn settings +See the [Omnibus GitLab Unicorn settings documentation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md) if you want to adjust these settings. diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md index 58a34607e2d..8b89c5e914e 100644 --- a/doc/administration/packages/container_registry.md +++ b/doc/administration/packages/container_registry.md @@ -360,9 +360,9 @@ The different supported drivers are: | Driver | Description | |------------|-------------------------------------| | filesystem | Uses a path on the local filesystem | -| azure | Microsoft Azure Blob Storage | +| Azure | Microsoft Azure Blob Storage | | gcs | Google Cloud Storage | -| s3 | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). | +| s3 | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). | | swift | OpenStack Swift Object Storage | | oss | Aliyun OSS | @@ -374,7 +374,7 @@ filesystem. Remember to enable backups with your object storage provider if desired. NOTE: **Note:** -`regionendpoint` is only required when configuring an S3 compatible service such as Minio. It takes a URL such as `http://127.0.0.1:9000`. +`regionendpoint` is only required when configuring an S3 compatible service such as MinIO. It takes a URL such as `http://127.0.0.1:9000`. **Omnibus GitLab installations** diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index d8f80965c21..eb230f02c0d 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -8,7 +8,7 @@ help GitLab administrators diagnose problem repositories so they can be fixed. There are 3 things that are checked to determine integrity. -1. Git repository file system check ([git fsck](https://git-scm.com/docs/git-fsck)). +1. Git repository file system check ([`git fsck`](https://git-scm.com/docs/git-fsck)). This step verifies the connectivity and validity of objects in the repository. 1. Check for `config.lock` in the repository directory. 1. Check for any branch/references lock files in `refs/heads`. diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md index 387bc71965b..09f72c3411d 100644 --- a/doc/administration/raketasks/geo.md +++ b/doc/administration/raketasks/geo.md @@ -2,7 +2,7 @@ ## Git housekeeping -There are few tasks you can run to schedule a git housekeeping to start at the +There are few tasks you can run to schedule a Git housekeeping to start at the next repository sync in a **Secondary node**: ### Incremental Repack diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md index 89335fcd2a8..e63e0c40393 100644 --- a/doc/administration/raketasks/maintenance.md +++ b/doc/administration/raketasks/maintenance.md @@ -62,7 +62,7 @@ It will check that each component was set up according to the installation guide You may also have a look at our Troubleshooting Guides: - [Troubleshooting Guide (GitLab)](../index.md#troubleshooting) -- [Troubleshooting Guide (Omnibus Gitlab)](https://docs.gitlab.com/omnibus/README.html#troubleshooting) +- [Troubleshooting Guide (Omnibus GitLab)](https://docs.gitlab.com/omnibus/README.html#troubleshooting) **Omnibus Installation** @@ -76,7 +76,7 @@ sudo gitlab-rake gitlab:check bundle exec rake gitlab:check RAILS_ENV=production ``` -NOTE: Use SANITIZE=true for gitlab:check if you want to omit project names from the output. +NOTE: Use `SANITIZE=true` for `gitlab:check` if you want to omit project names from the output. Example output: @@ -146,7 +146,7 @@ You will lose any data stored in authorized_keys file. Do you want to continue (yes/no)? yes ``` -## Clear redis cache +## Clear Redis cache If for some reason the dashboard shows wrong information you might want to clear Redis' cache. @@ -183,7 +183,7 @@ For omnibus versions, the unoptimized assets (JavaScript, CSS) are frozen at the release of upstream GitLab. The omnibus version includes optimized versions of those assets. Unless you are modifying the JavaScript / CSS code on your production machine after installing the package, there should be no reason to redo -rake gitlab:assets:compile on the production machine. If you suspect that assets +`rake gitlab:assets:compile` on the production machine. If you suspect that assets have been corrupted, you should reinstall the omnibus package. ## Tracking Deployments |