Add latest changes from gitlab-org/gitlab@master

doc/api/users.md

@@ -754,7 +754,7 @@ POST /user/keys
 Parameters:
 - `title` (required) - new SSH Key's title
-- `key` (required)   - new SSH key
+- `key` (required) - new SSH key
 ```json
 {
@@ -791,9 +791,9 @@ POST /users/:id/keys
 Parameters:
-- `id` (required)    - id of specified user
+- `id` (required) - id of specified user
 - `title` (required) - new SSH Key's title
-- `key` (required)   - new SSH key
+- `key` (required) - new SSH key
 ## Delete SSH key for current user
@@ -819,7 +819,7 @@ DELETE /users/:id/keys/:key_id
 Parameters:
 - `id` (required) - id of specified user
-- `key_id` (required)  - SSH key ID
+- `key_id` (required) - SSH key ID
 ## List all GPG keys
@@ -1130,7 +1130,7 @@ POST /users/:id/emails
 Parameters:
-- `id` (required)    - id of specified user
+- `id` (required) - id of specified user
 - `email` (required) - email address
 - `skip_confirmation` (optional) - Skip confirmation and assume e-mail is verified - true or false (default)
@@ -1158,7 +1158,7 @@ DELETE /users/:id/emails/:email_id
 Parameters:
 - `id` (required) - id of specified user
-- `email_id` (required)  - email ID
+- `email_id` (required) - email ID
 ## Block user

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -23,7 +23,7 @@ before_script:
   - php -r "unlink('composer-setup.php');"
 ```
-This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies  and `npm install` to load Node.js packages, then run the `npm` script. We need to append them  into `before_script` section:
+This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages, then run the `npm` script. We need to append them into `before_script` section:
 ```yaml
 before_script:

doc/ci/jenkins/index.md

@@ -53,7 +53,7 @@ There are some high level differences between the products worth mentioning:
   - by [webhook](../triggers/README.md#triggering-a-pipeline-from-a-webhook)
   - by [ChatOps](../chatops/README.md)
-  You can control which jobs run in which cases, depending on how they are triggered,
+- You can control which jobs run in which cases, depending on how they are triggered,
   with the [`rules` syntax](../yaml/README.md#rules).
 - GitLab [pipeline scheduling concepts](../pipelines/schedules.md) are also different than with Jenkins.
 - All jobs within a single stage always run in parallel, and all stages run in sequence. We are planning
@@ -78,7 +78,9 @@ There are some high level differences between the products worth mentioning:
   also leverage [`protected environments`](../yaml/README.md#protecting-manual-jobs-premium)
   to control who is able to approve them.
 - GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
-  container images to set up your build environment.
+  container images to set up your build environment. For example, set up one pipeline that builds your build environment
+  itself and publish that to the container registry. Then, have your pipelines use this instead of each building their
+  own environment, which will be slower and may be less consistent. We have extensive docs on [how to use the Container Registry](../../user/packages/container_registry/index.md).
 - Totally stuck and not sure where to turn for advice? The [GitLab community forum](https://forum.gitlab.com/) can be a great resource.
 ## Groovy vs. YAML

doc/ci/pipelines/schedules.md

@@ -86,7 +86,7 @@ To change the Sidekiq worker's frequency:
 1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file.
 1. [Reconfigure GitLab](../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
-For GitLab.com, refer to the [dedicated settings page](../../user/gitlab_com/index.md#cron-jobs).
+For GitLab.com, refer to the [dedicated settings page](../../user/gitlab_com/index.md#gitlab-cicd).
 ## Working with scheduled pipelines

doc/ci/review_apps/index.md

@@ -200,7 +200,8 @@ Feature.enable(:anonymous_visual_review_feedback)
 The feedback form is served through a script you add to pages in your Review App.
 If you have [Developer permissions](../../user/permissions.md) to the project,
 you can access it by clicking the **Review** button in the **Pipeline** section
-of the merge request.
+of the merge request. The form modal will also show a dropdown for changed pages
+if [route maps](#route-maps) are configured in the project.
 ![review button](img/review_button.png)

doc/ci/services/postgres.md

@@ -119,7 +119,7 @@ We have set up an [Example PostgreSQL Project][postgres-example-repo] for your
 convenience that runs on [GitLab.com](https://gitlab.com) using our publicly
 available [shared runners](../runners/README.md).
-Want to hack on it? Simply fork it, commit and push  your changes. Within a few
+Want to hack on it? Simply fork it, commit and push your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.
 [hub-pg]: https://hub.docker.com/_/postgres

doc/ci/services/redis.md

@@ -66,5 +66,5 @@ We have set up an [Example Redis Project](https://gitlab.com/gitlab-examples/red
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
-Want to hack on it? Simply fork it, commit and push  your changes. Within a few
+Want to hack on it? Simply fork it, commit and push your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.

doc/ci/triggers/README.md

@@ -123,7 +123,7 @@ settings page which provides self-explanatory examples.
 When a rerun of a pipeline is triggered, the information is exposed in GitLab's
 UI under the **Jobs** page and the jobs are marked as triggered 'by API'.
-![Marked rebuilds as  on jobs page](img/builds_page.png)
+![Marked rebuilds as on jobs page](img/builds_page.png)
 ---

doc/ci/yaml/README.md

@@ -867,6 +867,10 @@ CAUTION: **Warning:**
 There are some points to be aware of when
 [using this feature with new branches or tags *without* pipelines for merge requests](#using-onlychanges-without-pipelines-for-merge-requests).
+CAUTION: **Warning:**
+There are some points to be aware of when
+[using this feature with scheduled pipelines](#using-onlychanges-with-scheduled-pipelines).
+
 ##### Using `only:changes` with pipelines for merge requests
 With [pipelines for merge requests](../merge_request_pipelines/index.md),
@@ -931,6 +935,12 @@ This could result in some unexpected behavior, including:
 - When pushing a new commit, the changed files are calculated using the previous commit
   as the base SHA.
+##### Using `only:changes` with scheduled pipelines
+
+`only:changes` always evaluates as "true" in [Scheduled pipelines](../pipelines/schedules.md).
+All files are considered to have "changed" when a scheduled pipeline
+runs.
+
 ### `rules`
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29011) in GitLab 12.3.
@@ -3042,7 +3052,7 @@ include:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53903) in GitLab 11.7.
 To include files from another private project under the same GitLab instance,
-use `include:file`. This file is referenced using full  paths relative to the
+use `include:file`. This file is referenced using full paths relative to the
 root directory (`/`). For example:
 ```yaml

doc/development/code_review.md

@@ -455,7 +455,7 @@ helped us with overall code quality (using delegation, `&.` those
 types of things), and making the code more robust.
 **["Support multiple assignees for merge requests"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10161)**:
-A  good example of collaboration on an MR touching multiple parts of the codebase. Nick pointed out interesting edge cases, James Lopes also joined in raising concerns on import/export feature.
+A good example of collaboration on an MR touching multiple parts of the codebase. Nick pointed out interesting edge cases, James Lopes also joined in raising concerns on import/export feature.
 ### Credits

doc/development/contributing/issue_workflow.md

@@ -137,7 +137,7 @@ their color is `#A8D695`.
 with `_` replaced with a space.
 For instance, the "Continuous Integration" group is represented by the
-~"group::continuous integration"  label in the `gitlab-org` group since its key
+~"group::continuous integration" label in the `gitlab-org` group since its key
 under `stages.manage.groups` is `continuous_integration`.
 The current group labels can be found by [searching the labels list for `group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::).

doc/development/database_review.md

@@ -185,6 +185,6 @@ NOTE: **Note:** Keep in mind that all runtimes should be measured against GitLab
 | Migration Type | Execution Time Recommended | Notes |
 |----|----|---|
-| Regular migrations on `db/migrate` | `3 minutes` | A valid exception  are index creation as this can take a long time. |
+| Regular migrations on `db/migrate` | `3 minutes` | A valid exception are index creation as this can take a long time. |
 | Post migrations on `db/post_migrate` | `10 minutes` | |
 | Background migrations | --- | Since these are suitable for larger tables, it's not possible to set a precise timing guideline, however, any single query must stay below `1 second` execution time with cold caches. |

doc/development/fe_guide/development_process.md

@@ -4,7 +4,7 @@ You can find more about the organization of the frontend team in the [handbook](
 ## Development Checklist
-The idea is to remind us about specific topics during the time we build a new feature or start something. This is a common practice in other industries (like pilots) that also use  standardised checklists to reduce problems early on.
+The idea is to remind us about specific topics during the time we build a new feature or start something. This is a common practice in other industries (like pilots) that also use standardised checklists to reduce problems early on.
 Copy the content over to your issue or merge request and if something doesn't apply simply remove it from your current list.

doc/development/fe_guide/icons.md

@@ -65,7 +65,7 @@ export default {
 </template>
 ```
-- **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
+- **name** Name of the Icon in the SVG Sprite ([Overview is available here][svg-preview]).
 - **size (optional)** Number value for the size which is then mapped to a specific CSS class
   (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
 - **css-classes (optional)** Additional CSS Classes to add to the svg tag.

doc/development/file_storage.md

@@ -40,7 +40,7 @@ they are still not 100% standardized. You can see them below:
 | Issues/MR/Notes Legacy Markdown attachments | no | uploads/-/system/note/attachment/:id/:filename            | `AttachmentUploader`   | Note       |
 | Design Management design thumbnails (EE) | yes | uploads/-/system/design_management/action/image_v432x230/:id/:filename | `DesignManagement::DesignV432x230Uploader` | DesignManagement::Action |
 | CI Artifacts (CE)                     | yes    | `shared/artifacts/:disk_hash[0..1]/:disk_hash[2..3]/:disk_hash/:year_:month_:date/:job_id/:job_artifact_id` (:disk_hash is SHA256 digest of project_id) | `JobArtifactUploader`  | Ci::JobArtifact  |
-| LFS Objects  (CE)                     | yes    | shared/lfs-objects/:hex/:hex/:object_hash                   | `LfsObjectUploader`    | LfsObject  |
+| LFS Objects (CE)                      | yes    | shared/lfs-objects/:hex/:hex/:object_hash                   | `LfsObjectUploader`    | LfsObject  |
 | External merge request diffs          | yes    | shared/external-diffs/merge_request_diffs/mr-:parent_id/diff-:id | `ExternalDiffUploader` | MergeRequestDiff |
 CI Artifacts and LFS Objects behave differently in CE and EE. In CE they inherit the `GitlabUploader`

doc/development/permissions.md

@@ -9,11 +9,11 @@ anything that deals with permissions, all of them should be considered.
 Groups and projects can have the following visibility levels:
-- public (20) -  an entity is visible to everyone
+- public (20) - an entity is visible to everyone
 - internal (10) - an entity is visible to logged in users
 - private (0) - an entity is visible only to the approved members of the entity
-The visibility level of a group can be changed  only if all subgroups and
+The visibility level of a group can be changed only if all subgroups and
 subprojects have the same or lower visibility level. (e.g., a group can be set
 to internal only if all subgroups and projects are internal or private).

doc/development/query_recorder.md

@@ -65,7 +65,7 @@ There are multiple ways to find the source of queries.
    `QueryRecorder#occurrences_by_line_method` returns a sorted array based on `data`, sorted by `count`.
 1. You can output the call backtrace for the specific `QueryRecorder` instance you want
-   by using `ActiveRecord::QueryRecorder.new(query_recorder_debug: true)`.  The output
+   by using `ActiveRecord::QueryRecorder.new(query_recorder_debug: true)`. The output
    will be in `test.log`
 1. Using the environment variable `QUERY_RECORDER_DEBUG`, the call backtrace will be output for all tests.

doc/development/scalability.md

@@ -67,7 +67,7 @@ kind of partitioning.
 Sharding is likely more difficult and will require significant changes
 to the schema and application. For example, if we have to store projects
 in many different databases, we immediately run into the question, "How
-can we retrieve data across different projects?"  One answer to this is
+can we retrieve data across different projects?" One answer to this is
 to abstract data access into API calls that abstract the database from
 the application, but this is a significant amount of work.

doc/development/testing_guide/end_to_end/best_practices.md

@@ -10,7 +10,7 @@ But if the login feature is already covered with end-to-end tests through the GU
 Let's say that, on average, the process to perform a successful login through the GUI takes 2 seconds.
-Now, realize that almost all tests need the user to be logged in, and that we need every test to run in isolation, meaning that tests cannot interfere with each other. This would  mean that for every test the user needs to log in, and "waste 2 seconds".
+Now, realize that almost all tests need the user to be logged in, and that we need every test to run in isolation, meaning that tests cannot interfere with each other. This would mean that for every test the user needs to log in, and "waste 2 seconds".
 Now, multiply the number of tests per 2 seconds, and as your test suite grows, the time to run it grows with it, and this is not sustainable.

doc/development/testing_guide/end_to_end/quick_start_guide.md

@@ -39,7 +39,7 @@ Sometimes you may notice that there is already good coverage in lower test level
 - Take a look at the [How to test at the correct level?](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md#how-to-test-at-the-correct-level) section of the [Testing levels](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md) document
-- Look into the frequency in which such a feature is changed  (_Stable features that don't change very often might not be worth covering with end-to-end tests if they're already covered in lower levels_)
+- Look into the frequency in which such a feature is changed (_Stable features that don't change very often might not be worth covering with end-to-end tests if they're already covered in lower levels_)
 - Finally, discuss with the developer(s) involved in developing the feature and the tests themselves, to get their feeling