Add latest changes from gitlab-org/gitlab@master

5 files changed, 82 insertions, 5 deletions

diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md
index 5565eaa97f7..77f06b53ad3 100644
--- a/doc/api/project_import_export.md
+++ b/doc/api/project_import_export.md
@@ -88,6 +88,8 @@ an email notifying the user to download the file, uploading the exported file to
 
 `_links` are only present when export has finished.
 
+`created_at` is the project create timestamp, not the export start time.
+
 ```json
 {
   "id": 1,
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 40093167213..521969f2fcd 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -263,7 +263,7 @@ Depending on the status of your job, a badge can have the following values:
 You can access a pipeline status badge image using the following link:
 
 ```plaintext
-https://example.gitlab.com/<namespace>/<project>/badges/<branch>/pipeline.svg
+https://gitlab.example.com/<namespace>/<project>/badges/<branch>/pipeline.svg
 ```
 
 ### Test coverage report badge
@@ -275,7 +275,7 @@ pipeline can have the test coverage percentage value defined.
 The test coverage badge can be accessed using following link:
 
 ```plaintext
-https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg
+https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg
 ```
 
 If you would like to get the coverage report from a specific job, you can add
@@ -294,7 +294,7 @@ Pipeline badges can be rendered in different styles by adding the `style=style_n
 #### Flat (default)
 
 ```plaintext
-https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
+https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
 ```
 
 ![Badge flat style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat)
@@ -304,7 +304,7 @@ https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?st
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/30120) in GitLab 11.8.
 
 ```plaintext
-https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
+https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
 ```
 
 ![Badge flat square style](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage&style=flat-square)
diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index 0c8b712a001..ee94553c200 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -264,3 +264,77 @@ sequenceDiagram
       deactivate sidekiq
     end
 ```
+
+## How to add a new upload route
+
+In this section, we'll describe how to add a new upload route [accelerated](#uploading-technologies) by Workhorse for [body and multipart](#upload-encodings) encoded uploads.
+
+Uploads routes belong to one of these categories:
+
+1. Rails controllers: uploads handled by Rails controllers.
+1. Grape API: uploads handled by a Grape API endpoint.
+1. GraphQL API: uploads handled by a GraphQL resolve function. In these cases, there is nothing else
+   to do apart from implementing the actual upload.
+
+### Update Workhorse for the new route
+
+For both the Rails controller and Grape API uploads, Workhorse has to be updated in order to get the
+support for the new upload route.
+
+1. Open an new issue in the [Workhorse tracker](https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/new) describing precisely the new upload route:
+   - The route's URL.
+   - The [upload encoding](#upload-encodings).
+   - If possible, provide a dump of the upload request.
+1. Implement and get the MR merged for this issue above.
+1. Ask the Maintainers of [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) to create a new release. You can do that in the MR
+   directly during the maintainer review or ask for it in the `#workhorse` Slack channel.
+1. Bump the [Workhorse version file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/GITLAB_WORKHORSE_VERSION)
+   to the version you have from the previous points, or bump it in the same merge request that contains
+   the Rails changes (see [Implementing the new route with a Rails controller](#implementing-the-new-route-with-a-rails-controller) or [Implementing the new route with a Grape API endpoint](#implementing-the-new-route-with-a-grape-api-endpoint) below).
+
+### Implementing the new route with a Rails controller
+
+For a Rails controller upload, we usually have a [multipart](#upload-encodings) upload and there are a
+few things to do:
+
+1. The upload is available under the parameter name you're using. For example, it could be an `artifact`
+   or a nested parameter such as `user[avatar]`. Let's say that we have the upload under the
+   `file` parameter, reading `params[:file]` should get you an [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb) instance.
+1. Generally speaking, it's a good idea to check if the instance is from the [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb) class. For example, see how we checked
+[that the parameter is indeed an `UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/commit/ea30fe8a71bf16ba07f1050ab4820607b5658719#51c0cc7a17b7f12c32bc41cfab3649ff2739b0eb_79_77).
+
+CAUTION: **Caution:**
+**Do not** call `UploadedFile#from_params` directly! Do not build an [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb)
+instance using `UploadedFile#from_params`! This method can be unsafe to use depending on the `params`
+passed. Instead, use the [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb)
+instance that [`multipart.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/middleware/multipart.rb)
+builds automatically for you.
+
+### Implementing the new route with a Grape API endpoint
+
+For a Grape API upload, we can have [body or a multipart](#upload-encodings) upload. Things are slightly more complicated: two endpoints are needed. One for the
+Workhorse pre-upload authorization and one for accepting the upload metadata from Workhorse:
+
+1. Implement an endpoint with the URL + `/authorize` suffix that will:
+   - Check that the request is coming from Workhorse with the `require_gitlab_workhorse!` from the [API helpers](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/helpers.rb).
+   - Check user permissions.
+   - Set the status to `200` with `status 200`.
+   - Set the content type with `content_type Gitlab::Workhorse::INTERNAL_API_CONTENT_TYPE`.
+   - Use your dedicated `Uploader` class (let's say that it's `FileUploader`) to build the response with `FileUploader.workhorse_authorize(params)`.
+1. Implement the endpoint for the upload request that will:
+   - Require all the `UploadedFile` objects as parameters.
+      - For example, if we expect a single parameter `file` to be an [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb) instance,
+use `requires :file, type: ::API::Validations::Types::WorkhorseFile`.
+      - Body upload requests have their upload available under the parameter `file`.
+   - Check that the request is coming from Workhorse with the `require_gitlab_workhorse!` from the
+[API helpers](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/helpers.rb).
+   - Check the user permissions.
+   - The remaining code of the processing. This is where the code must be reading the parameter (for
+our example, it would be `params[:file]`).
+
+CAUTION: **Caution:**
+**Do not** call `UploadedFile#from_params` directly! Do not build an [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb)
+object using `UploadedFile#from_params`! This method can be unsafe to use depending on the `params`
+passed. Instead, use the [`UploadedFile`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/uploaded_file.rb)
+object that [`multipart.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/middleware/multipart.rb)
+builds automatically for you.
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index 5b90ec6f18c..c428e267a97 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -377,6 +377,7 @@ NPM_TOKEN=<your_token> npm install
 ### `npm install` returns `npm ERR! 403 Forbidden`
 
 - Check that your token is not expired and has appropriate permissions.
+- Check that [your token does not begin with `-`](https://gitlab.com/gitlab-org/gitlab/-/issues/235473).
 - Check if you have attempted to publish a package with a name that already exists within a given scope.
 - Ensure the scoped packages URL includes a trailing slash:
   - Correct: `//gitlab.com/api/v4/packages/npm/`
diff --git a/doc/user/project/static_site_editor/index.md b/doc/user/project/static_site_editor/index.md
index 4e401014122..ce14cefba92 100644
--- a/doc/user/project/static_site_editor/index.md
+++ b/doc/user/project/static_site_editor/index.md
@@ -82,7 +82,7 @@ or [create a new project from a template](../../../gitlab-basics/create-project.
 1. Visit your website and look at the bottom-left corner of the screen to see the new **Edit this page** button.
 
 Anyone satisfying the [requirements](#requirements) will be able to edit the
-content of the pages without prior knowledge of Git nor of your site's
+content of the pages without prior knowledge of Git or of your site's
 codebase.
 
 NOTE: **Note:**