kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

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

Browse source 
Update capitalization in /administration, /api, others

See merge request gitlab-org/gitlab-ce!32136
This commit is contained in:
Achilleas Pipinellis 2019-08-23 08:50:24 +00:00
commit d4502d75d5
24 changed files with 43 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/administration/container_registry.md
View file

@ -471,7 +471,7 @@ You can use GitLab as an auth endpoint and use a non-bundled Container Registry.
```
1. A certificate keypair is required for GitLab and the Container Registry to
communicate securely. By default omnibus-gitlab will generate one keypair,
communicate securely. By default Omnibus GitLab will generate one keypair,
which is saved to `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key`.
When using a non-bundled Container Registry, you will need to supply a
custom certificate key. To do that, add the following to
@ -487,7 +487,7 @@ You can use GitLab as an auth endpoint and use a non-bundled Container Registry.
**Note:** The file specified at `registry_key_path` gets populated with the
content specified by `internal_key`, each time reconfigure is executed. If
no file is specified, omnibus-gitlab will default it to
no file is specified, Omnibus GitLab will default it to
`/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` and will populate
it.

20
doc/administration/custom_hooks.md
View file

@ -12,17 +12,17 @@ NOTE: **Note:**
Custom Git hooks won't be replicated to secondary nodes if you use [GitLab Geo](geo/replication/index.md)
Git natively supports hooks that are executed on different actions.
Examples of server-side git hooks include pre-receive, post-receive, and update.
Examples of server-side Git hooks include pre-receive, post-receive, and update.
See [Git SCM Server-Side Hooks][hooks] for more information about each hook type.
As of gitlab-shell version 2.2.0 (which requires GitLab 7.5+), GitLab
administrators can add custom git hooks to any GitLab project.
As of GitLab Shell version 2.2.0 (which requires GitLab 7.5+), GitLab
administrators can add custom Git hooks to any GitLab project.
## Create a custom Git hook for a repository
Server-side Git hooks are typically placed in the repository's `hooks`
subdirectory. In GitLab, hook directories are symlinked to the gitlab-shell
`hooks` directory for ease of maintenance between gitlab-shell upgrades.
subdirectory. In GitLab, hook directories are symlinked to the GitLab Shell
`hooks` directory for ease of maintenance between GitLab Shell upgrades.
Custom hooks are implemented differently, but the behavior is exactly the same
once the hook is created. Follow the steps below to set up a custom hook for a
repository:
@ -36,7 +36,7 @@ repository:
1. Inside the new `custom_hooks` directory, create a file with a name matching
the hook type. For a pre-receive hook the file name should be `pre-receive`
with no extension.
1. Make the hook file executable and make sure it's owned by git.
1. Make the hook file executable and make sure it's owned by Git.
1. Write the code to make the Git hook function as expected. Hooks can be
in any language. Ensure the 'shebang' at the top properly reflects the language
type. For example, if the script is in Ruby the shebang will probably be
@ -49,17 +49,17 @@ as appropriate.
To create a Git hook that applies to all of your repositories in
your instance, set a global Git hook. Since all the repositories' `hooks`
directories are symlinked to gitlab-shell's `hooks` directory, adding any hook
to the gitlab-shell `hooks` directory will also apply it to all repositories. Follow
directories are symlinked to GitLab Shell's `hooks` directory, adding any hook
to the GitLab Shell `hooks` directory will also apply it to all repositories. Follow
the steps below to properly set up a custom hook for all repositories:
1. On the GitLab server, navigate to the configured custom hook directory. The
default is in the gitlab-shell directory. The gitlab-shell `hook` directory
default is in the GitLab Shell directory. The GitLab Shell `hook` directory
for an installation from source the path is usually
`/home/git/gitlab-shell/hooks`. For Omnibus installs the path is usually
`/opt/gitlab/embedded/service/gitlab-shell/hooks`.
To look in a different directory for the global custom hooks,
set `custom_hooks_dir` in the gitlab-shell config. For
set `custom_hooks_dir` in the GitLab Shell config. For
Omnibus installations, this can be set in `gitlab.rb`; and in source
installations, this can be set in `gitlab-shell/config.yml`.
1. Create a new directory in this location. Depending on your hook, it will be

2
doc/administration/dependency_proxy.md
View file

@ -48,7 +48,7 @@ local location or even use object storage.
The dependency proxy files for Omnibus GitLab installations are stored under
`/var/opt/gitlab/gitlab-rails/shared/dependency_proxy/` and for source
installations under `shared/dependency_proxy/` (relative to the git home directory).
installations under `shared/dependency_proxy/` (relative to the Git home directory).
To change the local storage path:
**Omnibus GitLab installations**

2
doc/administration/git_protocol.md
View file

@ -53,7 +53,7 @@ sudo service ssh restart
## Instructions
In order to use the new protocol, clients need to either pass the configuration
`-c protocol.version=2` to the git command, or set it globally:
`-c protocol.version=2` to the Git command, or set it globally:
```sh
git config --global protocol.version 2

4
doc/administration/incoming_email.md
View file

@ -151,7 +151,7 @@ Reply by email should now be working.
#### Postfix
Example configuration for Postfix mail server. Assumes mailbox incoming@gitlab.example.com.
Example configuration for Postfix mail server. Assumes mailbox `incoming@gitlab.example.com`.
Example for Omnibus installs:
@ -218,7 +218,7 @@ incoming_email:
#### Gmail
Example configuration for Gmail/G Suite. Assumes mailbox gitlab-incoming@gmail.com.
Example configuration for Gmail/G Suite. Assumes mailbox `gitlab-incoming@gmail.com`.
Example for Omnibus installs:

2
doc/administration/index.md
View file

@ -193,6 +193,6 @@ Learn how to install, configure, update, and maintain your GitLab instance.
for troubleshooting Kubernetes-related issues.
- Useful links from the Support Team:
- [GitLab Developer Docs](https://docs.gitlab.com/ee/development/README.html).
- [Repairing and recovering broken git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html).
- [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html).
- [Testing with OpenSSL](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html).
- [Strace zine](https://wizardzines.com/zines/strace/).

2
doc/administration/issue_closing_pattern.md
View file

@ -13,7 +13,7 @@ in the project's default branch.
In order to change the pattern you need to have access to the server that GitLab
is installed on.
The default pattern can be located in [gitlab.yml.example] under the
The default pattern can be located in [`gitlab.yml.example`] under the
"Automatic issue closing" section.
> **Tip:**

2
doc/administration/job_artifacts.md
View file

@ -94,7 +94,7 @@ If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need
### Object Storage Settings
For source installations the following settings are nested under `artifacts:` and then `object_store:`. On omnibus installs they are prefixed by `artifacts_object_store_`.
For source installations the following settings are nested under `artifacts:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `artifacts_object_store_`.
| Setting | Description | Default |
|---------|-------------|---------|

2
doc/administration/packages.md
View file

@ -55,7 +55,7 @@ local location or even use object storage.
The packages for Omnibus GitLab installations are stored under
`/var/opt/gitlab/gitlab-rails/shared/packages/` and for source
installations under `shared/packages/` (relative to the git homedir).
installations under `shared/packages/` (relative to the Git homedir).
To change the local storage path:
**Omnibus GitLab installations**

2
doc/administration/plugins.md
View file

@ -39,7 +39,7 @@ Follow the steps below to set up a custom hook:
1. Inside the `plugins` directory, create a file with a name of your choice,
without spaces or special characters.
1. Make the hook file executable and make sure it's owned by the git user.
1. Make the hook file executable and make sure it's owned by the Git user.
1. Write the code to make the plugin function as expected. That can be
in any language, and ensure the 'shebang' at the top properly reflects the
language type. For example, if the script is in Ruby the shebang will

2
doc/administration/reply_by_email_postfix_setup.md
View file

@ -18,7 +18,7 @@ The instructions make the assumption that you will be using the email address `i
sudo apt-get install postfix
```
When asked about the environment, select 'Internet Site'. When asked to confirm the hostname, make sure it matches gitlab.example.com`.
When asked about the environment, select 'Internet Site'. When asked to confirm the hostname, make sure it matches `gitlab.example.com`.
1. Install the `mailutils` package.

2
doc/administration/repository_checks.md
View file

@ -3,7 +3,7 @@
> [Introduced][ce-3232] in GitLab 8.7. It is OFF by default because it still
causes too many false alarms.
Git has a built-in mechanism, [git fsck][git-fsck], to verify the
Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
integrity of all data committed to a repository. GitLab administrators
can trigger such a check for a project via the project page under the
admin panel. The checks run asynchronously so it may take a few minutes

6
doc/administration/repository_storage_types.md
View file

@ -118,7 +118,7 @@ If you do have any existing integration, you may want to do a small rollout firs
to validate. You can do so by specifying a range with the operation.
This is an example of how to limit the rollout to Project IDs 50 to 100, running in
an Omnibus Gitlab installation:
an Omnibus GitLab installation:
```bash
sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
@ -139,7 +139,7 @@ To schedule a complete rollback, see the
[rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
The rollback task also supports specifying a range of Project IDs. Here is an example
of limiting the rollout to Project IDs 50 to 100, in an Omnibus Gitlab installation:
of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
```bash
sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100
@ -185,7 +185,7 @@ CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in
##### LFS Objects
LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following git own implementation:
LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following Git own implementation:
```ruby
"shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"

2
doc/administration/uploads.md
View file

@ -57,7 +57,7 @@ This configuration relies on valid AWS credentials to be configured already.
## Object Storage Settings
For source installations the following settings are nested under `uploads:` and then `object_store:`. On omnibus installs they are prefixed by `uploads_object_store_`.
For source installations the following settings are nested under `uploads:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `uploads_object_store_`.
| Setting | Description | Default |
|---------|-------------|---------|

4
doc/api/features.md
View file

@ -60,8 +60,8 @@ POST /features/:name
| `value` | integer/string | yes | `true` or `false` to enable/disable, or an integer for percentage of time |
| `feature_group` | string | no | A Feature group name |
| `user` | string | no | A GitLab username |
| `group` | string | no | A GitLab group's path, for example 'gitlab-org' |
| `project` | string | no | A projects path, for example 'gitlab-org/gitlab-ce' |
| `group` | string | no | A GitLab group's path, for example `gitlab-org` |
| `project` | string | no | A projects path, for example `gitlab-org/gitlab-ce` |
Note that you can enable or disable a feature for a `feature_group`, a `user`,
a `group`, and a `project` in a single API call.

2
doc/api/geo_nodes.md
View file

@ -111,7 +111,7 @@ PUT /geo_nodes/:id
|-----------------------------|---------|-----------|---------------------------------------------------------------------------|
| `id` | integer | yes | The ID of the Geo node. |
| `enabled` | boolean | no | Flag indicating if the Geo node is enabled. |
| `name` | string | yes | The unique identifier for the Geo node. Must match `geo_node_name` if it is set in gitlab.rb, otherwise it must match `external_url`. |
| `name` | string | yes | The unique identifier for the Geo node. Must match `geo_node_name` if it is set in `gitlab.rb`, otherwise it must match `external_url`. |
| `url` | string | yes | The user-facing URL of the Geo node. |
| `internal_url` | string | no | The URL defined on the primary node that secondary nodes should use to contact it. Returns `url` if not set.|
| `files_max_capacity` | integer | no | Control the maximum concurrency of LFS/attachment backfill for this secondary node. |

4
doc/api/lint.md
View file

@ -1,4 +1,4 @@
# Validate the .gitlab-ci.yml (API)
# Validate the `.gitlab-ci.yml` (API)
> [Introduced][ce-5953] in GitLab 8.12.
@ -10,7 +10,7 @@ POST /ci/lint
| Attribute | Type | Required | Description |
| ---------- | ------- | -------- | -------- |
| `content` | string | yes | the .gitlab-ci.yaml content|
| `content` | string | yes | the `.gitlab-ci.yaml` content|
```bash
curl --header "Content-Type: application/json" https://gitlab.example.com/api/v4/ci/lint --data '{"content": "{ \"image\": \"ruby:2.6\", \"services\": [\"postgres\"], \"before_script\": [\"bundle install\", \"bundle exec rake db:create\"], \"variables\": {\"DB_NAME\": \"postgres\"}, \"types\": [\"test\", \"deploy\", \"notify\"], \"rspec\": { \"script\": \"rake spec\", \"tags\": [\"ruby\", \"postgres\"], \"only\": [\"branches\"]}}"}'

4
doc/api/projects.md
View file

@ -2037,13 +2037,13 @@ Read more in the [Project Badges](project_badges.md) documentation.
The non-default [issue and merge request description templates](../user/project/description_templates.md) are managed inside the project's repository. So you can manage them via the API through the [Repositories API](repositories.md) and the [Repository Files API](repository_files.md).
## Download snapshot of a git repository
## Download snapshot of a Git repository
> Introduced in GitLab 10.7
This endpoint may only be accessed by an administrative user.
Download a snapshot of the project (or wiki, if requested) git repository. This
Download a snapshot of the project (or wiki, if requested) Git repository. This
snapshot is always in uncompressed [tar](https://en.wikipedia.org/wiki/Tar_(computing))
format.

2
doc/api/repository_files.md
View file

@ -246,7 +246,7 @@ error message. Possible causes for a failed commit include:
user tried to make an empty commit;
- the branch was updated by a Git push while the file edit was in progress.
Currently gitlab-shell has a boolean return code, preventing GitLab from specifying the error.
Currently GitLab Shell has a boolean return code, preventing GitLab from specifying the error.
## Delete existing file in repository

4
doc/api/settings.md
View file

@ -232,7 +232,7 @@ are listed in the descriptions of the relevant settings.
| `file_template_project_id` | integer | no | **(PREMIUM)** The ID of a project to load custom file templates from |
| `first_day_of_week` | integer | no | Start day of the week for calendar views and date pickers. Valid values are `0` (default) for Sunday, `1` for Monday, and `6` for Saturday. |
| `geo_status_timeout` | integer | no | **(PREMIUM)** The amount of seconds after which a request to get a secondary node status will time out. |
| `gitaly_timeout_default` | integer | no | Default Gitaly timeout, in seconds. This timeout is not enforced for git fetch/push operations or Sidekiq jobs. Set to `0` to disable timeouts. |
| `gitaly_timeout_default` | integer | no | Default Gitaly timeout, in seconds. This timeout is not enforced for Git fetch/push operations or Sidekiq jobs. Set to `0` to disable timeouts. |
| `gitaly_timeout_fast` | integer | no | Gitaly fast operation timeout, in seconds. Some Gitaly operations are expected to be fast. If they exceed this threshold, there may be a problem with a storage shard and 'failing fast' can help maintain the stability of the GitLab instance. Set to `0` to disable timeouts. |
| `gitaly_timeout_medium` | integer | no | Medium Gitaly timeout, in seconds. This should be a value between the Fast and the Default timeout. Set to `0` to disable timeouts. |
| `gravatar_enabled` | boolean | no | Enable Gravatar. |
@ -244,7 +244,7 @@ are listed in the descriptions of the relevant settings.
| `hide_third_party_offers` | boolean | no | Do not display offers from third parties within GitLab. |
| `home_page_url` | string | no | Redirect to this URL when not logged in. |
| `housekeeping_bitmaps_enabled` | boolean | required by: `housekeeping_enabled` | Enable Git pack file bitmap creation. |
| `housekeeping_enabled` | boolean | no | (**If enabled, requires:** `housekeeping_bitmaps_enabled`, `housekeeping_full_repack_period`, `housekeeping_gc_period`, and `housekeeping_incremental_repack_period`) Enable or disable git housekeeping. |
| `housekeeping_enabled` | boolean | no | (**If enabled, requires:** `housekeeping_bitmaps_enabled`, `housekeeping_full_repack_period`, `housekeeping_gc_period`, and `housekeeping_incremental_repack_period`) Enable or disable Git housekeeping. |
| `housekeeping_full_repack_period` | integer | required by: `housekeeping_enabled` | Number of Git pushes after which an incremental `git repack` is run. |
| `housekeeping_gc_period` | integer | required by: `housekeeping_enabled` | Number of Git pushes after which `git gc` is run. |
| `housekeeping_incremental_repack_period` | integer | required by: `housekeeping_enabled` | Number of Git pushes after which an incremental `git repack` is run. |

4
doc/api/tags.md
View file

@ -112,7 +112,7 @@ Parameters:
- `tag_name` (required) - The name of a tag
- `ref` (required) - Create tag using commit SHA, another tag name, or branch name.
- `message` (optional) - Creates annotated tag.
- `release_description` (optional) - Add release notes to the git tag and store it in the GitLab database.
- `release_description` (optional) - Add release notes to the Git tag and store it in the GitLab database.
```json
{
@ -166,7 +166,7 @@ Parameters:
## Create a new release
Add release notes to the existing git tag. If there
Add release notes to the existing Git tag. If there
already exists a release for the given tag, status code `409` is returned.
```

2
doc/ci/README.md
View file

@ -174,7 +174,7 @@ been necessary. These are:
#### 12.0
- [Use refspec to clone/fetch git
- [Use refspec to clone/fetch Git
repository](https://gitlab.com/gitlab-org/gitlab-runner/issues/4069).
- [Old cache
configuration](https://gitlab.com/gitlab-org/gitlab-runner/issues/4070).

4
doc/customization/libravatar.md
View file

@ -14,7 +14,7 @@ server.
## Configuration
In the [gitlab.yml gravatar section](https://gitlab.com/gitlab-org/gitlab-ce/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab-ce/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
the configuration options as follows:
### For HTTP
@ -46,7 +46,7 @@ For example, you host a service on `http://libravatar.example.com` and the
`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
### Omnibus-gitlab example
### Omnibus GitLab example
In `/etc/gitlab/gitlab.rb`:

2
doc/customization/system_header_and_footer_messages.md
View file

@ -8,7 +8,7 @@ Navigate to the **Admin** area and go to the **Appearance** page.
Under **System header and footer** insert your header message and/or footer message.
Both background and font color of the header and footer are customizable.
You can also apply the header and footer messages to gitlab emails,
You can also apply the header and footer messages to GitLab emails,
by checking the **Enable header and footer in emails** checkbox.
Note that color settings will only be applied within the app interface and not to emails