Commit 7ca65803 authored by Craig Norris's avatar Craig Norris

Merge branch 'docs-aqualls-create5' into 'master'

Yet more Create word / line revisions

See merge request gitlab-org/gitlab!52748
parents 207d0d1c a10dadae
......@@ -225,8 +225,8 @@ of some merge request diffs when [external diffs in object storage](#object-stor
were enabled. This mainly affected imported merge requests, and was resolved
with [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31005).
If you are using object storage, have never used on-disk storage for external
diffs, the "changes" tab for some merge requests fails to load with a 500 error,
If you are using object storage, or have never used on-disk storage for external
diffs, the **Changes** tab for some merge requests fails to load with a 500 error,
and the exception for that error is of this form:
```plain
......
......@@ -9,8 +9,8 @@ type: reference
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31025) in GitLab 12.3.
GitLab can be configured to serve repository static objects (for example, archives or raw blobs) from an external
storage, such as a Content Delivery Network (CDN).
You can configure GitLab to serve repository static objects, like archives or raw blobs,
from an external storage, such as a Content Delivery Network (CDN).
## Configuring
......@@ -19,19 +19,22 @@ To configure external storage for static objects:
1. Navigate to **Admin Area > Settings > Repository**.
1. Expand the **Repository static objects** section.
1. Enter the base URL and an arbitrary token. When you [set up external storage](#set-up-external-storage),
you'll use a script that uses these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
use a script that sets these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
The token is required to distinguish requests coming from the external storage, so users don't
circumvent the external storage and go for the application directly. The token is expected to be
set in the `X-Gitlab-External-Storage-Token` header in requests originating from the external
storage.
circumvent the external storage and access the application directly. GitLab expects
this token to be set in the `X-Gitlab-External-Storage-Token` header in requests
originating from the external storage.
## Serving private static objects
GitLab will append a user-specific token for static object URLs that belong to private projects,
so an external storage can be authenticated on behalf of the user. When processing requests originating
from the external storage, GitLab will look for the token in the `token` query parameter or in
the `X-Gitlab-Static-Object-Token` header to check the user's ability to access the requested object.
GitLab appends a user-specific token for static object URLs belonging to private projects,
so an external storage can be authenticated on the user's behalf. When processing requests originating
from the external storage, GitLab checks the following places to confirm the user may
access the requested object:
- The `token` query parameter.
- The `X-Gitlab-Static-Object-Token` header.
## Requests flow example
......@@ -66,8 +69,8 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
1. In the following script, set the following values for the first two constants:
- `ORIGIN_HOSTNAME`: the hostname of your GitLab installation.
- `STORAGE_TOKEN`: any arbitrary secure token (e.g. you can get one by running
`pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as
- `STORAGE_TOKEN`: any arbitrary secure token. You can get a token by running
`pwgen -cn1 64` on a UNIX machine. Save this token for the admin panel, as
described in the [configuring](#configuring) section.
```javascript
......
......@@ -225,8 +225,8 @@ Parameters:
- `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
- `snippet_id` (required) - The ID of a project's snippet
- `ref` (required) - The name of a branch, tag or commit e.g. master
- `file_path` (required) - The URL-encoded path to the file, e.g. snippet%2Erb
- `ref` (required) - The name of a branch, tag or commit, such as `master`
- `file_path` (required) - The URL-encoded path to the file, such as `snippet%2Erb`
Example request:
......@@ -239,7 +239,7 @@ curl "https://gitlab.com/api/v4/projects/1/snippets/2/files/master/snippet%2Erb/
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/29508) in GitLab 9.4.
Available only for admins.
Available only for users with Administrator [permissions](../user/permissions.md).
```plaintext
GET /projects/:id/snippets/:snippet_id/user_agent_detail
......
......@@ -4,25 +4,24 @@ group: Editor
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Migration to Versioned Snippets **(CORE ONLY)**
# Migration to versioned snippets **(CORE ONLY)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215861) in GitLab 13.0.
In GitLab 13.0, [GitLab Snippets are backed by Git repositories](../user/snippets.md#versioned-snippets).
This means that the snippet content will be stored in the repository
and users can update it directly through Git.
Snippet content is stored in the repository, and users can update it directly through Git.
Nevertheless, existing GitLab Snippets have to be migrated to this new functionality.
For each snippet, a new repository is created and the snippet content is committed
to the repository inside a file whose name is the filename used in the snippet
as well.
Nevertheless, existing GitLab Snippets must be migrated to this new feature.
For each snippet:
GitLab performs this migration through a [Background Migration](../development/background_migrations.md)
automatically when the GitLab instance is upgrade to 13.0 or a higher version.
However, if the migration fails for any of the snippets, they still need
to be migrated individually.
- A new repository is created.
- A file is created in the repository, using the snippet filename.
- The snippet is committed to the repository.
The following Rake tasks will help with that process.
GitLab performs this migration through a [Background Migration](../development/background_migrations.md)
when the GitLab instance is upgraded to 13.0 or a higher version.
However, if the migration fails for any of the snippets, they must be migrated individually.
The following Rake tasks help with that process.
## Migrate specific snippets to Git
......
......@@ -17,8 +17,8 @@ project.
![Find file button](img/file_finder_find_button_v12_10.png)
For those who prefer to keep their fingers on the keyboard, there is a
[shortcut button](../../shortcuts.md) as well, which you can invoke from _anywhere_
If you prefer to keep their fingers on the keyboard, use the
[shortcut button](../../shortcuts.md), which you can invoke from anywhere
in a project.
Press `t` to launch the File search function when in **Issues**,
......
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