Add latest changes from gitlab-org/gitlab@master

doc/ci/caching/index.md

@@ -320,8 +320,8 @@ cache:
     - vendor/ruby
 
 before_script:
-  - ruby -v                                   # Print out ruby version for debugging
-  - bundle install -j $(nproc) --path vendor  # Install dependencies into ./vendor/ruby
+  - ruby -v                                        # Print out ruby version for debugging
+  - bundle install -j $(nproc) --path vendor/ruby  # Install dependencies into ./vendor/ruby
 
 rspec:
   script:

doc/ci/large_repositories/index.md

@@ -31,14 +31,14 @@ it often results in receiving extra commit logs.
 
 Ideally, you should always use `GIT_DEPTH` with a small number
 like 10. This will instruct GitLab Runner to perform shallow clones.
-Shallow clones makes Git request only the latest set of changes for a given branch,
+Shallow clones make Git request only the latest set of changes for a given branch,
 up to desired number of commits as defined by the `GIT_DEPTH` variable.
 
 This significantly speeds up fetching of changes from Git repositories,
 especially if the repository has a very long backlog consisting of number
 of big files as we effectively reduce amount of data transfer.
 
-The following example makes GitLab Runner shallow clone to fetch only a given branch,
+The following example makes GitLab Runner shallow clone to fetch only a given branch;
 it does not fetch any other branches nor tags.
 
 ```yaml
@@ -107,7 +107,7 @@ clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
 -e .build/`, for example, allows you to control and disable removal of some
 directories within the worktree between subsequent runs, which can speed-up
 the incremental builds. This has the biggest effect if you re-use existing
-machines, and have an existing worktree that you can re-use for builds.
+machines and have an existing worktree that you can re-use for builds.
 
 For exact parameters accepted by
 [`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
@@ -118,19 +118,19 @@ are dependent on Git version.
 
 > Introduced in GitLab Runner 11.10.
 
-Following the guidelines above, lets imagine that we want to:
+Following the guidelines above, let's imagine that we want to:
 
 - Optimize for a big project (more than 50k files in directory).
 - Use forks-based workflow for contributing.
 - Reuse existing worktrees. Have preconfigured runners that are pre-cloned with repositories.
 - Runner assigned only to project and all forks.
 
-Lets consider the following two examples, one using `shell` executor and
+Let's consider the following two examples, one using `shell` executor and
 other using `docker` executor.
 
 ### `shell` executor example
 
-Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
+Let's assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
 
 ```toml
 concurrent = 4
@@ -155,7 +155,7 @@ This `config.toml`:
 
 ### `docker` executor example
 
-Lets assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
+Let's assume that you have the following [config.toml](https://docs.gitlab.com/runner/configuration/advanced-configuration.html).
 
 ```toml
 concurrent = 4
@@ -238,5 +238,5 @@ concurrent = 4
     volumes = ["/builds:/builds", "/cache:/cache"]
 ```
 
-This makes the cloning configuration to be part of given Runner,
+This makes the cloning configuration to be part of given Runner
 and does not require us to update each `.gitlab-ci.yml`.

doc/ci/parent_child_pipelines.md

@@ -31,7 +31,7 @@ set of concurrently running child pipelines, but within the same project:
 - The configuration is split up into smaller child pipeline configurations, which are
   easier to understand. This reduces the cognitive load to understand the overall configuration.
 - Imports are done at the child pipeline level, reducing the likelihood of collisions.
-- Each pipeline has only the steps relevant steps, making it easier to understand what's going on.
+- Each pipeline has only relevant steps, making it easier to understand what's going on.
 
 Child pipelines work well with other GitLab CI features:
 
@@ -40,7 +40,7 @@ Child pipelines work well with other GitLab CI features:
 - Since the parent pipeline in `.gitlab-ci.yml` and the child pipeline run as normal
   pipelines, they can have their own behaviors and sequencing in relation to triggers.
 
-All of this will work with [`include:`](yaml/README.md#include) feature so you can compose
+All of this will work with the [`include:`](yaml/README.md#include) feature so you can compose
 the child pipeline configuration.
 
 ## Examples

doc/raketasks/backup_restore.md

@@ -740,6 +740,7 @@ running:
 
 ```shell
 sudo gitlab-ctl stop unicorn
+sudo gitlab-ctl stop puma
 sudo gitlab-ctl stop sidekiq
 # Verify
 sudo gitlab-ctl status