Add latest changes from gitlab-org/gitlab@master

doc/administration/gitaly/praefect.md

@@ -631,7 +631,7 @@ and replication jobs will be created to replicate repository data to `internal_s
 #### Automatic failover
 
 When automatic failover is enabled, Praefect will do automatic detection of the health of internal Gitaly nodes. If the
-primary has a certain amount of healthchecks fail, it will decide to promote one of the secondaries to be primary, and
+primary has a certain amount of health checks fail, it will decide to promote one of the secondaries to be primary, and
 demote the primary to be a secondary.
 
 1. To enable automatic failover, edit `/etc/gitlab/gitlab.rb`:

doc/administration/troubleshooting/linux_cheat_sheet.md

@@ -215,7 +215,7 @@ Top 25 PIDs
 ```
 
 Based on the summary, you can then view the details of syscalls made by one or more
-procsses using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for
+processes using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for
 a sorted list. `--stats` takes the same sorting and count options as summary.
 
 ```shell

doc/administration/troubleshooting/ssl.md

@@ -7,7 +7,7 @@ type: reference
 This page contains a list of common SSL-related errors and scenarios that you may face while working with GitLab.
 It should serve as an addition to the main SSL docs available here:
 
-- [Omniibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html)
+- [Omnibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html)
 - [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html)
 - [Manually configuring HTTPS](https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https)
 

doc/api/group_badges.md

@@ -9,7 +9,7 @@ Badges support placeholders that will be replaced in real time in both the link
 - **%{project_path}**: will be replaced by the project path.
 - **%{project_id}**: will be replaced by the project id.
 - **%{default_branch}**: will be replaced by the project default branch.
-- **%{commit_sha}**: will be replaced by the last project's commit sha.
+- **%{commit_sha}**: will be replaced by the last project's commit SHA.
 
 Because these endpoints aren't inside a project's context, the information used to replace the placeholders will be
 from the first group's project by creation date. If the group hasn't got any project the original URL with the placeholders will be returned.

doc/api/merge_request_context_commits.md

@@ -51,7 +51,7 @@ POST /projects/:id/merge_requests/
 
 | Attribute                  | Type    | Required | Description                                                                     |
 | ---------                  | ----    | -------- | -----------                                                                     |
-| `commits`             | string array | yes | The context commits' sha  |
+| `commits`             | string array | yes | The context commits' SHA  |
 
 ```json
 [
@@ -86,4 +86,4 @@ Parameters:
 
 | Attribute                  | Type    | Required | Description                                                                     |
 | ---------                  | ----    | -------- | -----------                                                                     |
-| `commits`             | string array | yes | The context commits' sha  |
+| `commits`             | string array | yes | The context commits' SHA  |

doc/api/pipelines.md

@@ -14,7 +14,7 @@ GET /projects/:id/pipelines
 | `scope`   | string  | no       | The scope of pipelines, one of: `running`, `pending`, `finished`, `branches`, `tags` |
 | `status`  | string  | no       | The status of pipelines, one of: `running`, `pending`, `success`, `failed`, `canceled`, `skipped`, `created` |
 | `ref`     | string  | no       | The ref of pipelines |
-| `sha`     | string  | no       | The sha of pipelines |
+| `sha`     | string  | no       | The SHA of pipelines |
 | `yaml_errors`| boolean  | no       | Returns pipelines with invalid configurations |
 | `name`| string  | no       | The name of the user who triggered pipelines |
 | `username`| string  | no       | The username of the user who triggered pipelines |

doc/ci/caching/index.md

@@ -265,7 +265,7 @@ test:
 
 Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install
 the Python dependencies, the following example defines `cache` globally so that
-all jobs inherit it. Python libraries are installed in a virtualenv under `venv/`,
+all jobs inherit it. Python libraries are installed in a virtual environment under `venv/`,
 pip's cache is defined under `.cache/pip/` and both are cached per-branch:
 
 ```yaml

doc/ci/jenkins/index.md

@@ -185,7 +185,7 @@ In self-managed GitLab instances, you can build an [Instance Template Repository
 Development teams across the whole organization can select templates from a dropdown menu.
 A group administrator is able to set a group to use as the source for the
 [custom project templates](../../user/admin_area/custom_project_templates.md), which can
-be used by all projects in the group. An instance adminsitrator can set a group as
+be used by all projects in the group. An instance administrator can set a group as
 the source for [instance project templates](../../user/group/custom_project_templates.md),
 which can be used by projects in that instance.
 

doc/ci/merge_request_pipelines/index.md

@@ -7,40 +7,32 @@ last_update: 2019-07-03
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/15310) in GitLab 11.6.
 
-Usually, when you create a new merge request, a pipeline runs with the
-new change and checks if it's qualified to be merged into a target branch. This
-pipeline should contain only necessary jobs for validating the new changes.
-For example, unit tests, lint checks, and [Review Apps](../review_apps/index.md)
-are often used in this cycle.
+In a [basic configuration](../pipelines/pipeline_architectures.md), GitLab runs a pipeline each time
+changes are pushed to a branch. The settings in the [`.gitlab-ci.yml`](../yaml/README.md)
+file, including `rules`, `only`, and `except`, determine which jobs are added to a pipeline.
 
-With pipelines for merge requests, you can design a specific pipeline structure
-for when you are running a pipeline in a merge request. This
-could be either adding or removing steps in the pipeline, to make sure that
-your pipelines are as efficient as possible.
+If you want the pipeline to run jobs **only** when merge requests are created or updated,
+you can use *pipelines for merge requests*.
 
-## Requirements and limitations
+In the UI, these pipelines are labeled as `detached`.
 
-Pipelines for merge requests have the following requirements and limitations:
+![Merge request page](img/merge_request.png)
+
+A few notes:
 
-- As of GitLab 11.10, pipelines for merge requests require GitLab Runner 11.9
-  or higher due to the
-  [recent refspecs changes](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25504).
 - Pipelines for merge requests are incompatible with
   [CI/CD for external repositories](../ci_cd_for_external_repos/index.md).
+- [Since GitLab 11.10](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25504), pipelines for merge requests require GitLab Runner 11.9.
 
 ## Configuring pipelines for merge requests
 
 To configure pipelines for merge requests, add the `only: [merge_requests]` parameter to
-the jobs that you want to run only for merge requests.
-
-Then, when developers create or update merge requests, a pipeline runs
-every time a commit is pushed to GitLab.
+your `.gitlab-ci.yml` file.
 
-NOTE: **Note**:
-If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
-pipelines for merge requests take precedence over the other regular pipelines.
+In this example, the pipeline contains a `test` job that is configured to run on merge requests.
 
-For example, consider the following [`.gitlab-ci.yml`](../yaml/README.md):
+The `build` and `deploy` jobs don't have the `only: - merge_requests` parameter,
+so they will not run on merge requests.
 
 ```yaml
 build:
@@ -62,19 +54,14 @@ deploy:
   - master
 ```
 
-After the merge request is updated with new commits:
+Whenever a merge request is updated with new commits:
 
 - GitLab detects that changes have occurred and creates a new pipeline for the merge request.
 - The pipeline fetches the latest code from the source branch and run tests against it.
 
-In the above example, the pipeline contains only a `test` job.
-Since the `build` and `deploy` jobs don't have the `only: [merge_requests]` parameter,
-they will not run in the merge request.
-
-Pipelines tagged with the **detached** badge indicate that they were triggered
-when a merge request was created or updated. For example:
-
-![Merge request page](img/merge_request.png)
+NOTE: **Note**:
+If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
+pipelines for merge requests take precedence over the other regular pipelines.
 
 ## Pipelines for Merged Results **(PREMIUM)**
 
@@ -129,10 +116,8 @@ Therefore:
 - Since `C` specifies that it should only run for merge requests, it will not run for any pipeline
   except a merge request pipeline.
 
-As you can see, this will help you avoid a lot of boilerplate where you'd need
-to add that `only:` rule to all of your jobs in order to make them always run. You
-can use this for scenarios like having only pipelines with merge requests get a
-Review App set up, helping to save resources.
+This helps you avoid having to add the `only:` rule to all of your jobs
+in order to make them always run. You can use this format to set up a Review App, helping to save resources.
 
 ## Excluding certain branches
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -7,31 +7,32 @@ last_update: 2019-07-03
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7380) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
-It's possible for your source and target branches to diverge, which can result
-in the scenario that source branch's pipeline was green, the target's pipeline was green,
-but the combined output fails.
-
-By having your merge request pipeline automatically
-create a new ref that contains the merge result of the source and target branch
-(then running a pipeline on that ref), we can better test that the combined result
-is also valid.
-
-GitLab can run pipelines for merge requests
-on this merged result. That is, where the source and target branches are combined into a
-new ref and a pipeline for this ref validates the result prior to merging.
-
-![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png)
-
-There are some cases where creating a combined ref is not possible or not wanted.
-For example, a source branch that has conflicts with the target branch
-or a merge request that is still in WIP status. In this case,
-GitLab doesn't create a merge commit and the pipeline runs on source branch, instead,
-which is a default behavior of [Pipelines for merge requests](../index.md)
- i.e. `detached` label is shown to the pipelines.
-
-The detached state serves to warn you that you are working in a situation
-subjected to merge problems, and helps to highlight that you should
-get out of WIP status or resolve merge conflicts as soon as possible.
+When you submit a merge request, you are requesting to merge changes from a
+source branch into a target branch. By default, the CI pipeline runs jobs
+against the source branch.
+
+With *pipelines for merged results*, the pipeline runs as if the changes from
+the source branch have already been merged into the target branch.
+
+If the pipeline fails due to a problem in the target branch, you can wait until the
+target is fixed and re-run the pipeline.
+This new pipeline will run as if the source is merged with the updated target, and you
+will not need to rebase.
+
+The pipeline does not automatically run when the target branch changes. Only changes
+to the source branch trigger a new pipeline. If a long time has passed since the last successful
+pipeline, you may want to re-run it before merge, to ensure that the source changes
+can still be successfully merged into the target.
+
+When the merge request can't be merged, the pipeline runs against the source branch only. For example, when:
+
+- The target branch has changes that conflict with the changes in the source branch.
+- The merge request is a
+  [work in progress](../../../user/project/merge_requests/work_in_progress_merge_requests.md).
+
+In these cases, the pipeline runs as a [pipeline for merge requests](../index.md)
+and is labeled as `detached`. If these cases no longer exist, new pipelines will
+again run against the merged results.
 
 ## Requirements and limitations
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -8,31 +8,57 @@ last_update: 2019-07-03
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9186) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.0.
 > - [Squash and merge](../../../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/issues/13001) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6.
 
-[Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) introduces
-running a build on the result of the merged code prior to merging, as a way to keep master green.
+When [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
+enabled, the pipeline jobs run as if the changes from your source branch have already
+been merged into the target branch.
 
-There's a scenario, however, for teams with a high number of changes in the target branch (typically master) where in many or even all cases,
-by the time the merged code is validated another commit has made it to master, invalidating the merged result.
-You'd need some kind of queuing, cancellation or retry mechanism for these scenarios
-in order to ensure an orderly flow of changes into the target branch.
+However, the target branch may be changing rapidly. When you're ready to merge,
+if you haven't run the pipeline in a while, the target branch may have already changed.
+Merging now could introduce breaking changes.
 
-Each MR that joins a merge train joins as the last item in the train,
-just as it works in the current state. However, instead of queuing and waiting,
-each item takes the completed state of the previous (pending) merge ref, adds its own changes,
-and starts the pipeline immediately in parallel under the assumption that everything is going to pass.
+*Merge trains* can prevent this from happening. A merge train is a queued list of merge
+requests, each waiting to be merged into the target branch.
 
-This means that if all the pipelines in the train merge successfully, no pipeline time is wasted either queuing or retrying.
-If the button is subsequently pressed in a different MR, instead of creating a new pipeline for the target branch,
-it creates a new pipeline targeting the merge result of the previous MR plus the target branch.
-Pipelines invalidated through failures are immediately canceled and requeued.
+Each merge request on the train runs the merged results pipeline immediately before its
+changes are merged into the target branch. If the pipeline fails, the breaking changes are
+not merged, and the target branch is unaffected.
+
+Many merge requests can be added to the train. Each is trying to merge into the target branch.
+Each request runs its own merged results pipeline, which includes the changes from
+all of the other merge requests in *front* of it on the train. All the pipelines run
+in parallel, to save time.
+
+If the pipeline for the merge request at the front of the train completes successfully,
+the changes are merged into the target branch, and the other pipelines will continue to
+run.
+
+If one of the pipelines fails, it is removed from the train, and all pipelines behind
+it restart, but without the changes that were removed.
+
+Three merge requests (`A`, `B` and `C`) are added to a merge train in order, which
+creates three merged results pipelines that run in parallel:
+
+1. The first pipeline runs on the changes from `A` combined with the target branch.
+1. The second pipeline runs on the changes from `A` and `B` combined with the target branch.
+1. The third pipeline runs on the changes from `A`, `B`, and `C` combined with the target branch.
+
+If the pipeline for `B` fails, it is removed from the train. The pipeline for
+`C` restarts with the `A` and `C` changes, but without the `B` changes.
+
+If `A` then completes successfully, it merges into the target branch, and `C` continues
+to run. If more merge requests are added to the train, they will now include the `A`
+changes that are included in the target branch, and the `C` changes that are from
+the merge request already in the train.
+
+Learn more about
+[how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
 ## Requirements and limitations
 
 Merge trains have the following requirements and limitations:
 
-- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher to run Merge Trains.
-- This feature requires that
-  [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
+- GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher.
+- [Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) must be
   **configured properly**.
 - Each merge train can run a maximum of **twenty** pipelines in parallel.
   If more than twenty merge requests are added to the merge train, the merge requests
@@ -70,7 +96,7 @@ current position will be displayed under the pipeline widget:
 ## Start/Add to merge train when pipeline succeeds
 
 You can add a merge request to a merge train only when the latest pipeline in the
-merge request finished. While the pipeline is running or pending, you cannot add
+merge request is finished. While the pipeline is running or pending, you cannot add
 the merge request to a train because the current change of the merge request may
 be broken thus it could affect the following merge requests.
 

doc/development/api_graphql_styleguide.md

@@ -537,7 +537,7 @@ Arguments can be defined within the resolver, those arguments will be
 made available to the fields using the resolver. When exposing a model
 that had an internal ID (`iid`), prefer using that in combination with
 the namespace path as arguments in a resolver over a database
-ID. Othewise use a [globally unique ID](#exposing-global-ids).
+ID. Otherwise use a [globally unique ID](#exposing-global-ids).
 
 We already have a `FullPathLoader` that can be included in other
 resolvers to quickly find Projects and Namespaces which will have a

doc/development/architecture.md

@@ -230,7 +230,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
 - Process: `praefect`
 
 Praefect is a transparent proxy between each Git client and the Gitaly coordinating the replication of
-repository updates to secondairy nodes.
+repository updates to secondary nodes.
 
 #### GitLab Geo
 

doc/development/documentation/site_architecture/index.md

@@ -214,7 +214,7 @@ for its search function. This is how it works:
 
 1. GitLab is a member of the [docsearch program](https://community.algolia.com/docsearch/#join-docsearch-program),
    which is the free tier of [Algolia](https://www.algolia.com/).
-1. Algolia hosts a [doscsearch config](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json)
+1. Algolia hosts a [DocSearch configuration](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json)
    for the GitLab docs site, and we've worked together to refine it.
 1. That [config](https://community.algolia.com/docsearch/config-file.html) is
    parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html)

doc/development/documentation/site_architecture/release_process.md

@@ -11,7 +11,7 @@ The following Dockerfiles are used.
 | ---------- | ------------ | ----------- |
 | [`Dockerfile.bootstrap`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.bootstrap) | `gitlab-docs:bootstrap` | Contains all the dependencies that are needed to build the website. If the gems are updated and `Gemfile{,.lock}` changes, the image must be rebuilt. |
 | [`Dockerfile.builder.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.builder.onbuild) | `gitlab-docs:builder-onbuild` | Base image to build the docs website. It uses `ONBUILD` to perform all steps and depends on `gitlab-docs:bootstrap`. |
-| [`Dockerfile.nginx.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.nginx.onbuild) | `gitlab-docs:nginx-onbuild` | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation achives (see the `Dockerfile` of each branch. |
+| [`Dockerfile.nginx.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.nginx.onbuild) | `gitlab-docs:nginx-onbuild` | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation archives (see the `Dockerfile` of each branch. |
 | [`Dockerfile.archives`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/dockerfiles/Dockerfile.archives) | `gitlab-docs:archives` | Contains all the versions of the website in one archive. It copies all generated HTML files from every version in one location. |
 
 ## How to build the images

doc/development/fe_guide/droplab/droplab.md

@@ -185,11 +185,11 @@ DropLab adds some CSS classes to help lower the barrier to integration.
 
 For example:
 
-- The `droplab-item-selected` css class is added to items that have been selected
+- The `droplab-item-selected` CSS class is added to items that have been selected
   either by a mouse click or by enter key selection.
-- The `droplab-item-active` css class is added to items that have been selected
+- The `droplab-item-active` CSS class is added to items that have been selected
   using arrow key navigation.
-- You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example,
+- You can add the `droplab-item-ignore` CSS class to any item that you do not want to be selectable. For example,
   an `<li class="divider"></li>` list divider element that should not be interactive.
 
 ## Internal events

doc/development/fe_guide/style/vue.md

@@ -75,7 +75,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 1. **Props Naming:**  Avoid using DOM component prop names.
 1. **Props Naming:** Use kebab-case instead of camelCase to provide props in templates.
 
-   ```javascript
+   ```html
    // bad
    <component class="btn">
 
@@ -97,7 +97,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
    1. With more than one attribute, all attributes should be on a new line:
 
-      ```javascript
+      ```html
       // bad
       <component v-if="bar"
           param="baz" />
@@ -117,7 +117,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
    1. The tag can be inline if there is only one attribute:
 
-      ```javascript
+      ```html
       // good
         <component bar="bar" />
 
@@ -238,7 +238,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
 1. Shorthand `@` is preferable over `v-on`
 
-   ```javascript
+   ```html
    // bad
    <component v-on:click="eventHandler"/>
 
@@ -248,7 +248,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
 1. Shorthand `:` is preferable over `v-bind`
 
-   ```javascript
+   ```html
    // bad
    <component v-bind:class="btn"/>
 
@@ -258,7 +258,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
 1. Shorthand `#` is preferable over `v-slot`
 
-   ```javascript
+   ```html
    // bad
    <template v-slot:header></template>
 
@@ -270,7 +270,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
 1. Prefer self-closing component tags
 
-   ```javascript
+   ```html
    // bad
    <component></component>
 
@@ -282,7 +282,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
 
 1. Prefer a component's kebab-cased name over other styles when using it in a template
 
-   ```javascript
+   ```html
    // bad
    <MyComponent />
 
@@ -372,7 +372,7 @@ Useful links:
 
 1. Tooltips: Do not rely on `has-tooltip` class name for Vue components
 
-   ```javascript
+   ```html
    // bad
    <span
      class="has-tooltip"
@@ -392,7 +392,7 @@ Useful links:
 
 1. Don't change `data-original-title`.
 
-   ```javascript
+   ```html
    // bad
    <span data-original-title="tooltip text">Foo</span>
 

doc/development/geo.md

@@ -238,7 +238,7 @@ limited by its own restrictions. The credentials are configured as a
 FDW configuration and credentials definition are managed automatically by the
 Omnibus GitLab `gitlab-ctl reconfigure` command.
 
-#### Refeshing the Foreign Tables
+#### Refreshing the Foreign Tables
 
 Whenever a new Geo node is configured or the database schema changes on the
 **primary** node, you must refresh the foreign tables on the **secondary** node

doc/development/go_guide/index.md

@@ -242,7 +242,7 @@ to make the test output easily readable.
 - Ideally, each test case should have a field with a unique identifier
   to use for naming subtests. In the Go standard library, this is commonly the
   `name string` field.
-- Use `want`/`expect`/`actual` when you are specifcing something in the
+- Use `want`/`expect`/`actual` when you are specifying something in the
   test case that will be used for assertion.
 
 #### Variable names

doc/development/import_export.md

 # Import/Export development documentation
 
-Troubleshooing and general development guidelines and tips for the [Import/Export feature](../user/project/settings/import_export.md).
+Troubleshooting and general development guidelines and tips for the [Import/Export feature](../user/project/settings/import_export.md).
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> This document is originally based on the [Import/Export 201 presentation available on YouTube](https://www.youtube.com/watch?v=V3i1OfExotE).
 

doc/development/internal_api.md

@@ -187,8 +187,8 @@ Example response:
 
 ## Instance information
 
-This get's some generic information about the instance. This is used
-by Geo nodes to get information about eachother
+This gets some generic information about the instance. This is used
+by Geo nodes to get information about each other
 
 ```plaintext
 GET /internal/check

doc/development/merge_request_performance_guidelines.md

@@ -435,7 +435,7 @@ We can consider the following types of storages:
 ### Temporary storage
 
 The storage on production nodes is really sparse. The application should be built
-in a way that accomodates running under very limited temporary storage.
+in a way that accommodates running under very limited temporary storage.
 You can expect the system on which your code runs has a total of `1G-10G`
 of temporary storage. However, this storage is really shared across all
 jobs being run. If your job requires to use more than `100MB` of that space

doc/development/sidekiq_style_guide.md

@@ -255,7 +255,7 @@ discouraged, and alternative approaches to processing the work should be
 considered.
 
 If a worker needs large amounts of both memory and CPU time, it should
-be marked as memory-bound, due to the above restrction on high urgency
+be marked as memory-bound, due to the above restriction on high urgency
 memory-bound workers.
 
 ## Declaring a Job as CPU-bound

doc/development/testing_guide/review_apps.md

@@ -210,7 +210,7 @@ secure note named `gitlab-{ce,ee} Review App's root password`.
 
 If [Review App Stability](https://app.periscopedata.com/app/gitlab/496118/Engineering-Productivity-Sandbox?widget=6690556&udv=785399)
 dips this may be a signal that the `review-apps-ce/ee` cluster is unhealthy.
-Leading indicators may be healthcheck failures leading to restarts or majority failure for Review App deployments.
+Leading indicators may be health check failures leading to restarts or majority failure for Review App deployments.
 
 The [Review Apps Overview dashboard](https://app.google.stackdriver.com/dashboards/6798952013815386466?project=gitlab-review-apps&timeDomain=1d)
 aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy.

doc/integration/elasticsearch.md

@@ -631,7 +631,7 @@ Here are some common pitfalls and how to overcome them:
    Gitlab::Elastic::Indexer::Error: time="2020-01-23T09:13:00Z" level=fatal msg="health check timeout: no Elasticsearch node available"
    ```
 
-   You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be acceped as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
+   You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
    Once you have corrected the formatting of the URL, delete the index (via the [dedicated rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
 
 ### Reverting to basic search

doc/integration/salesforce.md

@@ -23,7 +23,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
    - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
    - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (OpenID)** to the right column.
 
-   ![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
+   ![Salesforce OAuth App Details](img/salesforce_oauth_app_details.png)
 
 1. Click **Save**.
 

doc/integration/vault.md

@@ -103,7 +103,7 @@ The following assumes you already have Vault installed and running.
    vault login -method=oidc port=8250 role=demo
    ```
 
-   Here is a short explaination of what this command does:
+   Here is a short explanation of what this command does:
 
    1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
    1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.

doc/topics/web_application_firewall/quick_start_guide.md

@@ -238,7 +238,7 @@ $ kubectl -n gitlab-managed-apps exec -it $(kubectl get pods -n gitlab-managed-a
 }
 ```
 
-You can see that ModSecurity logs the suspicous behavior. By sending a request
+You can see that ModSecurity logs the suspicious behavior. By sending a request
 with the `User Agent: absinthe` header, which [absinthe](https://github.com/cameronhotchkies/Absinthe), a tool for testing for SQL injections uses, we can detect that someone was
 searching for vulnerabilities on our system. Detecting scanners is useful, because we
 can learn if someone is trying to exploit our system.

doc/university/process/README.md

@@ -22,9 +22,9 @@ please submit a merge request to add an upcoming class, assign to
 1. To allow people to contribute all content should be in Git.
 1. The content can go in a subdirectory under `/doc/university/`.
 1. To make, view or modify the slides of the classes use [Deckset](https://www.deckset.com)
-   or [RevealJS](https://revealjs.com/#/). Do not use Powerpoint or Google
+   or [RevealJS](https://revealjs.com/#/). Do not use PowerPoint or Google
    Slides since this prevents everyone from contributing.
-1. Please upload any video recordings to our Youtube channel. We prefer them to
+1. Please upload any video recordings to our YouTube channel. We prefer them to
    be public, if needed they can be unlisted but if so they should be linked from
    this page.
 1. Please create a merge request and assign to [Erica](https://gitlab.com/Erica).

doc/user/discussions/index.md

@@ -447,7 +447,7 @@ instead of the usual three.
 
 ![A comment editor with a suggestion with a fenced code block](img/suggestion_code_block_editor_v12_8.png)
 
-![Ouput of a comment with a suggestion with a fenced code block](img/suggestion_code_block_output_v12_8.png)
+![Output of a comment with a suggestion with a fenced code block](img/suggestion_code_block_output_v12_8.png)
 
 ### Configure the commit message for applied Suggestions
 

doc/user/project/clusters/serverless/aws.md

@@ -368,7 +368,7 @@ variables.
 To set these:
 
 1. Navigate to the project's **{settings}** **Settings > CI / CD**.
-1. Expand the **Variables** section and create entires for `AWS_ACCESS_KEY_ID` and
+1. Expand the **Variables** section and create entries for `AWS_ACCESS_KEY_ID` and
    `AWS_SECRET_ACCESS_KEY`.
 1. Mask the credentials so they do not show in logs using the **Masked** toggle.
 

doc/user/project/issues/csv_export.md

@@ -61,7 +61,7 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 | Assignee Username | Username of the author, with the `@` symbol omitted |
 | Confidential | `Yes` or `No` |
 | Locked | `Yes` or `No` |
-| Due Date | Formated as `YYYY-MM-DD` |
+| Due Date | Formatted as `YYYY-MM-DD` |
 | Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
 | Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
 | Milestone | Title of the issue milestone |

doc/user/project/labels.md

@@ -175,7 +175,7 @@ For example, `workflow::backend::review` and `workflow::backend::development` ar
 scoped labels, but they **can't** exist on the same issue at the same time, as they
 both share the same scope, `workflow::backend`.
 
-Addtionally, `workflow::backend::review` and `workflow::frontend::review` are valid
+Additionally, `workflow::backend::review` and `workflow::frontend::review` are valid
 scoped labels, and they **can** exist on the same issue at the same time, as they
 both have different scopes, `workflow::frontend` and `workflow::backend`.
 

doc/user/project/merge_requests/test_coverage_visualization.md

@@ -22,7 +22,7 @@ You can specify one or more coverage reports to collect, including wildcard path
 GitLab will then take the coverage information in all the files and combine it
 together.
 
-For the coverage analysis to work, you have to provide a properly formated
+For the coverage analysis to work, you have to provide a properly formatted
 [Cobertura XML](https://cobertura.github.io/cobertura/) report to
 [`artifacts:reports:cobertura`](../../../ci/yaml/README.md#artifactsreportscobertura).
 This format was originally developed for Java, but most coverage analysis frameworks

doc/user/project/web_ide/index.md

@@ -46,11 +46,8 @@ Single file editing is based on the [Ace Editor](https://ace.c9.io).
 ## Commit changes
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4539) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4 and [brought to GitLab Core](https://gitlab.com/gitlab-org/gitlab-foss/issues/44157) in 10.7.
-> - From [GitLab 12.7 onwards](https://gitlab.com/gitlab-org/gitlab/issues/33441),
-files were automatically staged.
-> - From [GitLab 12.9 onwards](https://gitlab.com/gitlab-org/gitlab/-/issues/196609), support for staging files was removed
-to prevent loss of unstaged data. All your current changes necessarily have to be
-committed or discarded.
+> - From [GitLab 12.7 onward](https://gitlab.com/gitlab-org/gitlab/issues/33441), files were automatically staged.
+> - From [GitLab 12.9 onward](https://gitlab.com/gitlab-org/gitlab/-/issues/196609), support for staging files was removed to prevent loss of unstaged data. All your current changes necessarily have to be committed or discarded.
 
 After making your changes, click the **Commit** button on the bottom-left to
 review the list of changed files.

lib/gitlab/sidekiq_middleware/duplicate_jobs/client.rb

@@ -5,6 +5,9 @@ module Gitlab
     module DuplicateJobs
       class Client
         def call(worker_class, job, queue, _redis_pool, &block)
+          # We don't try to deduplicate jobs that are scheduled in the future
+          return yield if job['at']
+
           DuplicateJob.new(job, queue).schedule(&block)
         end
       end

spec/lib/gitlab/sidekiq_middleware/duplicate_jobs/client_spec.rb

@@ -30,5 +30,15 @@ describe Gitlab::SidekiqMiddleware::DuplicateJobs::Client, :clean_gitlab_redis_q
       expect(job2['duplicate-of']).to be_nil
       expect(job3['duplicate-of']).to eq(job1['jid'])
     end
+
+    it "does not mark a job that's scheduled in the future as a duplicate" do
+      TestDeduplicationWorker.perform_async('args1')
+      TestDeduplicationWorker.perform_at(1.day.from_now, 'args1')
+      TestDeduplicationWorker.perform_in(3.hours, 'args1')
+
+      duplicates = TestDeduplicationWorker.jobs.map { |job| job['duplicate-of'] }
+
+      expect(duplicates).to all(be_nil)
+    end
   end
 end