Skip to content
Snippets Groups Projects
Commit bd1dd5a4 authored by feistel's avatar feistel
Browse files

Fix more vale warnings

Related to group: Distribution
parent cf9f323c
No related branches found
No related tags found
1 merge request!91631Fix more vale warnings
Showing
with 41 additions and 41 deletions
......@@ -80,13 +80,13 @@ Nodes should be:
- Upgraded one node at a time.
Identify any existing health issues in the cluster by running the following command
within each node. The command will return an empty array if the cluster is healthy:
within each node. The command returns an empty array if the cluster is healthy:
```shell
curl "http://127.0.0.1:8500/v1/health/state/critical"
```
If the Consul version has changed, you'll see a notice at the end of `gitlab-ctl reconfigure`
If the Consul version has changed, you see a notice at the end of `gitlab-ctl reconfigure`
informing you that Consul needs to be restarted for the new version to be used.
Restart Consul one node at a time:
......@@ -149,7 +149,7 @@ To be safe, it's recommended that you only restart Consul in one node at a time
ensure the cluster remains intact. For larger clusters, it is possible to restart
multiple nodes at a time. See the
[Consul consensus document](https://www.consul.io/docs/architecture/consensus#deployment-table)
for the number of failures it can tolerate. This will be the number of simultaneous
for the number of failures it can tolerate. This is the number of simultaneous
restarts it can sustain.
To restart Consul:
......
......@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Housekeeping **(FREE SELF)**
GitLab supports and automates housekeeping tasks within your current repository such as:
GitLab supports and automates housekeeping tasks in your current repository such as:
- Compressing Git objects.
- Removing unreachable objects.
......
......@@ -7,7 +7,7 @@ type: reference
# GitLab application limits **(FREE SELF)**
GitLab, like most large applications, enforces limits within certain features to maintain a
GitLab, like most large applications, enforces limits in certain features to maintain a
minimum quality of performance. Allowing some features to be limitless could affect security,
performance, data, or could even exhaust the allocated resources for the application.
......@@ -309,7 +309,7 @@ Blocked recursive webhook calls are logged in `auth.log` with the message `"Recu
The [minimum wait time between pull refreshes](../user/project/repository/mirror/index.md)
defaults to 300 seconds (5 minutes). For example, a pull refresh only runs once in a given 300 second period, regardless of how many times you trigger it.
This setting applies in the context of pull refreshes invoked via the [projects API](../api/projects.md#start-the-pull-mirroring-process-for-a-project), or when forcing an update by selecting the **Update now** (**{retry}**) button within **Settings > Repository > Mirroring repositories**. This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for [pull mirroring](../user/project/repository/mirror/pull.md).
This setting applies in the context of pull refreshes invoked via the [projects API](../api/projects.md#start-the-pull-mirroring-process-for-a-project), or when forcing an update by selecting **Update now** (**{retry}**) in **Settings > Repository > Mirroring repositories**. This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for [pull mirroring](../user/project/repository/mirror/pull.md).
To change this limit for a self-managed installation, run the following in the
[GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
......@@ -342,7 +342,7 @@ and to limit memory consumption.
When using offset-based pagination in the REST API, there is a limit to the maximum
requested offset into the set of results. This limit is only applied to endpoints that
support keyset-based pagination. More information about pagination options can be
found in the [API docs section on pagination](../api/index.md#pagination).
found in the [API documentation section on pagination](../api/index.md#pagination).
To set this limit for a self-managed installation, run the following in the
[GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
......@@ -944,7 +944,7 @@ The maximum allowed [push size](../user/admin_area/settings/account_and_limit_se
Total number of changes (branches or tags) in a single push. If changes are more
than the specified limit, hooks are not executed.
More information can be found in these docs:
More information can be found in these documentations:
- [Webhooks push events](../user/project/integrations/webhook_events.md#push-events)
- [Project services push hooks limit](../user/project/integrations/index.md#push-hooks-limit)
......@@ -1040,7 +1040,7 @@ In addition to application-based limits, GitLab.com is configured to use Cloudfl
## Container Repository tag deletion limit
Container repository tags are in the Container Registry and, as such, each tag deletion will trigger network requests to the Container Registry. Because of this, we limit the number of tags that a single API call can delete to 20.
Container repository tags are in the Container Registry and, as such, each tag deletion triggers network requests to the Container Registry. Because of this, we limit the number of tags that a single API call can delete to 20.
## Project-level Secure Files API limits
......
......@@ -137,7 +137,7 @@ GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee
to lowest precedence:
- `|` - the logical `OR` operator. For example, `query_a|query_b` (where `query_a`
and `query_b` are queries made up of the other operators here) will include
and `query_b` are queries made up of the other operators here) includes
queues that match either query.
- `&` - the logical `AND` operator. For example, `query_a&query_b` (where
`query_a` and `query_b` are queries made up of the other operators here) will
......@@ -181,7 +181,7 @@ sidekiq['routing_rules'] = [
]
```
These queues will also need to be included in at least one [Sidekiq
These queues must also be included in at least one [Sidekiq
queue group](extra_sidekiq_processes.md#start-multiple-processes).
The following table shows the workers that should have their own queue:
......
......@@ -24,7 +24,7 @@ Keep your GitLab instance up and running smoothly.
of SSH certificates](ssh_certificates.md).
- [File System Performance Benchmarking](filesystem_benchmarking.md): File system
performance can have a big impact on GitLab performance, especially for actions
that read or write Git repositories. This information will help benchmark
that read or write Git repositories. This information helps benchmark
file system performance against known good and bad real-world systems.
- [The Rails Console](rails_console.md): Provides a way to interact with your GitLab instance from the command line.
Used for troubleshooting a problem or retrieving some data that can only be done through direct access to GitLab.
......
......@@ -96,7 +96,7 @@ Match User git
AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers
```
This command will emit output that looks something like:
This command emits output that looks something like:
```shell
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty {PRINCIPAL}
......
......@@ -31,7 +31,7 @@ Read more about update policies and warnings in the PostgreSQL
| -------------- | --------------------- | ---------------------------------- | ---------------------------- | ----- |
| 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
| 14.1 | 12.7, 13.3 | 12.7 | 12.7 | PostgreSQL 13 available for fresh installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-with-omnibus-gitlab).
| 14.0 | 12.7 | 12.7 | 12.7 | HA installations with repmgr are no longer supported and will be prevented from upgrading to Omnibus GitLab 14.0 |
| 14.0 | 12.7 | 12.7 | 12.7 | HA installations with repmgr are no longer supported and are prevented from upgrading to Omnibus GitLab 14.0 |
| 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster.). |
| 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
| 13.4 | 11.9, 12.4 | 11.9 | 11.9 | Package upgrades aborted if users not running PostgreSQL 11 already |
......
......@@ -234,7 +234,7 @@ sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
Sometimes during version upgrades you might end up with some wrong CSS or
missing some icons. In that case, try to precompile the assets again.
This only applies to source installations and does NOT apply to
This only applies to source installations and does not apply to
Omnibus packages.
**Source Installation**
......
......@@ -55,7 +55,7 @@ bundle exec rake gitlab:smtp:secret:edit RAILS_ENV=production EDITOR=vim
### Write raw secret
Write new secret content by providing it on STDIN.
Write new secret content by providing it on `STDIN`.
**Omnibus Installation**
......
......@@ -44,7 +44,7 @@ Omnibus GitLab:
1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
1. Note the Redis node's IP address or hostname, port, and
Redis password. These will be necessary when [configuring the GitLab application servers](#set-up-the-gitlab-rails-application-instance).
Redis password. These are necessary when [configuring the GitLab application servers](#set-up-the-gitlab-rails-application-instance).
[Advanced configuration options](https://docs.gitlab.com/omnibus/settings/redis.html)
are supported and can be added if needed.
......
......@@ -41,7 +41,7 @@ You can check if everything is correct by connecting to each server using
/opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
```
When connected to a `Primary` Redis, you will see the number of connected
When connected to a `Primary` Redis, you see the number of connected
`replicas`, and a list of each with connection details:
```plaintext
......@@ -56,7 +56,7 @@ repl_backlog_first_byte_offset:206989083
repl_backlog_histlen:1048576
```
When it's a `replica`, you will see details of the primary connection and if
When it's a `replica`, you see details of the primary connection and if
its `up` or `down`:
```plaintext
......@@ -138,7 +138,7 @@ there may be something wrong with your configuration files or it can be related
to [this upstream issue](https://github.com/redis/redis-rb/issues/531).
You must make sure that `resque.yml` and `sentinel.conf` are configured correctly,
otherwise `redis-rb` will not work properly.
otherwise `redis-rb` does not work properly.
The `master-group-name` (`gitlab-redis`) defined in (`sentinel.conf`)
**must** be used as the hostname in GitLab (`resque.yml`):
......
......@@ -54,20 +54,20 @@ This can result in some of the following problems:
- If GitLab is using non-secure HTTP to access the object storage, clients may generate
`https->http` downgrade errors and refuse to process the redirect. The solution to this
is for GitLab to use HTTPS. LFS, for example, will generate this error:
is for GitLab to use HTTPS. LFS, for example, generates this error:
```plaintext
LFS: lfsapi/client: refusing insecure redirect, https->http
```
- Clients will need to trust the certificate authority that issued the object storage
- Clients must trust the certificate authority that issued the object storage
certificate, or may return common TLS errors such as:
```plaintext
x509: certificate signed by unknown authority
```
- Clients will need network access to the object storage. Errors that might result
- Clients need network access to the object storage. Errors that might result
if this access is not in place include:
```plaintext
......@@ -113,7 +113,7 @@ You can check if everything is correct by connecting to each server using
/opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
```
When connected to a `Primary` Redis, you will see the number of connected
When connected to a `Primary` Redis, you see the number of connected
`replicas`, and a list of each with connection details:
```plaintext
......@@ -128,7 +128,7 @@ repl_backlog_first_byte_offset:206989083
repl_backlog_histlen:1048576
```
When it's a `replica`, you will see details of the primary connection and if
When it's a `replica`, you see details of the primary connection and if
its `up` or `down`:
```plaintext
......@@ -254,7 +254,7 @@ To start a session:
sudo gitlab-ctl pgb-console
```
The password you will be prompted for is the `pgbouncer_user_password`
The password you are prompted for is the `pgbouncer_user_password`
To get some basic information about the instance, run
......@@ -315,7 +315,7 @@ sudo gitlab-ctl tail patroni
### Consul and PostgreSQL with Patroni changes not taking effect
Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it will not restart the services. However, not all changes can be activated by reloading.
Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it does not restart the services. However, not all changes can be activated by reloading.
To restart either service, run `gitlab-ctl restart consul` or `gitlab-ctl restart patroni` respectively.
......@@ -335,7 +335,7 @@ PG::ConnectionBad: ERROR: pgbouncer cannot connect to server
The problem may be that your PgBouncer node's IP address is not included in the
`trust_auth_cidr_addresses` setting in `/etc/gitlab/gitlab.rb` on the database nodes.
You can confirm that this is the issue by checking the PostgreSQL log on the master
You can confirm that this is the issue by checking the PostgreSQL log on the primary
database node. If you see the following error then `trust_auth_cidr_addresses`
is the problem.
......
......@@ -206,7 +206,7 @@ To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure)
for the changes to take effect.
When TLS is enabled, the same `port` and `address` will be used as described above.
When TLS is enabled, the same `port` and `address` are used as described above.
The metrics server cannot serve both HTTP and HTTPS at the same time.
## Configure health checks
......
......@@ -29,7 +29,7 @@ session by running:
ActiveRecord::Base.logger = Logger.new($stdout)
```
This will show information about database queries triggered by any Ruby code
This shows information about database queries triggered by any Ruby code
you may run in the console. To turn off logging again, run:
```ruby
......@@ -45,8 +45,8 @@ session by running:
ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
```
This change only affects the current Rails console session and will
not be persisted in the GitLab production environment or in the next Rails
This change only affects the current Rails console session and is
not persisted in the GitLab production environment or in the next Rails
console session.
### Output Rails console session history
......@@ -164,7 +164,7 @@ in Omnibus, run as root:
## Common Problems
Many of the tips to diagnose issues below apply to many different situations. We'll use one
Many of the tips to diagnose issues below apply to many different situations. We 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
......@@ -214,7 +214,7 @@ downtime. Otherwise skip to the next section.
```
If the Puma process terminates before you are able to run these
commands, GDB will report an error. To buy more time, you can always raise the
commands, GDB reports an error. To buy more time, you can always raise the
Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
increase it from 60 seconds to 600:
......
......@@ -47,7 +47,7 @@ grep <TERM> <FILE> | jq .
jq -cR 'fromjson?' file.json | jq <COMMAND>
```
By default `jq` will error out when it encounters a line that is not valid JSON.
By default `jq` errors out when it encounters a line that is not valid JSON.
This skips over all invalid lines and parses the rest.
#### Print a JSON log's time range
......
......@@ -236,7 +236,7 @@ remote server that is serving only HTTP.
One scenario is that you're using [object storage](../object_storage.md), which
isn't served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
but the object storage will respond with plain HTTP.
but the object storage responds with plain HTTP.
## `schannel: SEC_E_UNTRUSTED_ROOT`
......
......@@ -45,7 +45,7 @@ docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
-d jamedjo/test-saml-idp
```
The following will also need to go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
The following must also go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
for more, as well as the list of [default usernames, passwords, and emails](https://hub.docker.com/r/jamedjo/test-saml-idp/#usage).
```ruby
......
......@@ -32,7 +32,7 @@ documentation for some popular browsers.
To locate a relevant request and view its correlation ID:
1. Enable persistent logging in your network monitor. Some actions in GitLab will redirect you quickly after you submit a form, so this will help capture all relevant activity.
1. Enable persistent logging in your network monitor. Some actions in GitLab redirect you quickly after you submit a form, so this helps capture all relevant activity.
1. To help isolate the requests you are looking for, you can filter for `document` requests.
1. Select the request of interest to view further detail.
1. Go to the **Headers** section and look for **Response Headers**. There you should find an `x-request-id` header with a
......@@ -121,7 +121,7 @@ find /var/log/gitlab -type f -mtime 0 -exec grep 'LOt9hgi1TV4' '{}' '+'
### Searching in distributed architectures
If you have done some horizontal scaling in your GitLab infrastructure, then
you will need to search across _all_ of your GitLab nodes. You can do this with
you must search across _all_ of your GitLab nodes. You can do this with
some sort of log aggregation software like Loki, ELK, Splunk, or others.
You can use a tool like Ansible or PSSH (parallel SSH) that can execute identical commands across your servers in
......
......@@ -66,7 +66,7 @@ For source installations the following settings are nested under `uploads:` and
| Setting | Description | Default |
|---------|-------------|---------|
| `enabled` | Enable/disable object storage | `false` |
| `remote_directory` | The bucket name where Uploads will be stored| |
| `remote_directory` | The bucket name where Uploads are stored| |
| `proxy_download` | Set to `true` to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` |
| `connection` | Various connection options described below | |
......
......@@ -21,7 +21,7 @@ For example, the `git` user is allowed to write in the `log/` directory, in
`public/uploads`, and they are allowed to rewrite the `db/structure.sql` file.
In other cases, the reconfigure script tricks GitLab into not trying to write a
file. For instance, GitLab will generate a `.secret` file if it cannot find one
file. For instance, GitLab generates a `.secret` file if it cannot find one
and write it to the Rails root. In the Omnibus packages, reconfigure writes the
`.secret` file first, so that GitLab never tries to write it.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment