Add latest changes from gitlab-org/gitlab@13-2-stable-ee

3 files changed, 69 insertions, 66 deletions

diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 65b9c03186b..4bed6d9e323 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -123,7 +123,7 @@ not without its own challenges:
 - By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is
   the recommended storage driver. See [Using the overlayfs driver](#use-the-overlayfs-driver)
   for details.
-- Since the `docker:19.03.11-dind` container and the Runner container don't share their
+- Since the `docker:19.03.12-dind` container and the Runner container don't share their
   root filesystem, the job's working directory can be used as a mount point for
   child containers. For example, if you have files you want to share with a
   child container, you may create a subdirectory under `/builds/$CI_PROJECT_PATH`
@@ -142,14 +142,14 @@ not without its own challenges:
 An example project using this approach can be found here: <https://gitlab.com/gitlab-examples/docker>.
 
 In the examples below, we are using Docker images tags to specify a
-specific version, such as `docker:19.03.11`. If tags like `docker:stable`
+specific version, such as `docker:19.03.12`. If tags like `docker:stable`
 are used, you have no control over what version is going to be used and this
 can lead to unpredictable behavior, especially when new versions are
 released.
 
 #### TLS enabled
 
-NOTE: **Note**
+NOTE: **Note:**
 Requires GitLab Runner 11.11 or later, but is not supported if GitLab
 Runner is installed using the [Helm
 chart](https://docs.gitlab.com/runner/install/kubernetes.html). See the
@@ -158,7 +158,7 @@ issue](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/83) for
 details.
 
 The Docker daemon supports connection over TLS and it's done by default
-for Docker 19.03.11 or higher. This is the **suggested** way to use the
+for Docker 19.03.12 or higher. This is the **suggested** way to use the
 Docker-in-Docker service and
 [GitLab.com Shared Runners](../../user/gitlab_com/index.md#shared-runners)
 support this.
@@ -174,13 +174,13 @@ support this.
      --registration-token REGISTRATION_TOKEN \
      --executor docker \
      --description "My Docker Runner" \
-     --docker-image "docker:19.03.11" \
+     --docker-image "docker:19.03.12" \
      --docker-privileged \
      --docker-volumes "/certs/client"
    ```
 
    The above command will register a new Runner to use the special
-   `docker:19.03.11` image, which is provided by Docker. **Notice that it's
+   `docker:19.03.12` image, which is provided by Docker. **Notice that it's
    using the `privileged` mode to start the build and service
    containers.** If you want to use [Docker-in-Docker](https://www.docker.com/blog/docker-can-now-run-within-docker/) mode, you always
    have to use `privileged = true` in your Docker containers.
@@ -199,7 +199,7 @@ support this.
      executor = "docker"
      [runners.docker]
        tls_verify = false
-       image = "docker:19.03.11"
+       image = "docker:19.03.12"
        privileged = true
        disable_cache = false
        volumes = ["/certs/client", "/cache"]
@@ -209,10 +209,10 @@ support this.
    ```
 
 1. You can now use `docker` in the build script (note the inclusion of the
-   `docker:19.03.11-dind` service):
+   `docker:19.03.12-dind` service):
 
    ```yaml
-   image: docker:19.03.11
+   image: docker:19.03.12
 
    variables:
      # When using dind service, we need to instruct docker, to talk with
@@ -237,7 +237,7 @@ support this.
      DOCKER_TLS_CERTDIR: "/certs"
 
    services:
-     - docker:19.03.11-dind
+     - docker:19.03.12-dind
 
    before_script:
      - docker info
@@ -264,7 +264,7 @@ Assuming that the Runner `config.toml` is similar to:
   executor = "docker"
   [runners.docker]
     tls_verify = false
-    image = "docker:19.03.11"
+    image = "docker:19.03.12"
     privileged = true
     disable_cache = false
     volumes = ["/cache"]
@@ -274,10 +274,10 @@ Assuming that the Runner `config.toml` is similar to:
 ```
 
 You can now use `docker` in the build script (note the inclusion of the
-`docker:19.03.11-dind` service):
+`docker:19.03.12-dind` service):
 
 ```yaml
-image: docker:19.03.11
+image: docker:19.03.12
 
 variables:
   # When using dind service we need to instruct docker, to talk with the
@@ -298,7 +298,7 @@ variables:
   DOCKER_TLS_CERTDIR: ""
 
 services:
-  - docker:19.03.11-dind
+  - docker:19.03.12-dind
 
 before_script:
   - docker info
@@ -318,7 +318,7 @@ container so that Docker is available in the context of that image.
 NOTE: **Note:**
 If you bind the Docker socket [when using GitLab Runner 11.11 or
 newer](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1261),
-you can no longer use `docker:19.03.11-dind` as a service because volume bindings
+you can no longer use `docker:19.03.12-dind` as a service because volume bindings
 are done to the services as well, making these incompatible.
 
 In order to do that, follow the steps:
@@ -333,12 +333,12 @@ In order to do that, follow the steps:
      --registration-token REGISTRATION_TOKEN \
      --executor docker \
      --description "My Docker Runner" \
-     --docker-image "docker:19.03.11" \
+     --docker-image "docker:19.03.12" \
      --docker-volumes /var/run/docker.sock:/var/run/docker.sock
    ```
 
    The above command will register a new Runner to use the special
-   `docker:19.03.11` image which is provided by Docker. **Notice that it's using
+   `docker:19.03.12` image which is provided by Docker. **Notice that it's using
    the Docker daemon of the Runner itself, and any containers spawned by Docker
    commands will be siblings of the Runner rather than children of the Runner.**
    This may have complications and limitations that are unsuitable for your workflow.
@@ -352,7 +352,7 @@ In order to do that, follow the steps:
      executor = "docker"
      [runners.docker]
        tls_verify = false
-       image = "docker:19.03.11"
+       image = "docker:19.03.12"
        privileged = false
        disable_cache = false
        volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
@@ -361,11 +361,11 @@ In order to do that, follow the steps:
    ```
 
 1. You can now use `docker` in the build script (note that you don't need to
-   include the `docker:19.03.11-dind` service as when using the Docker in Docker
+   include the `docker:19.03.12-dind` service as when using the Docker in Docker
    executor):
 
    ```yaml
-   image: docker:19.03.11
+   image: docker:19.03.12
 
    before_script:
      - docker info
@@ -419,10 +419,10 @@ any image that's used with the `--cache-from` argument must first be pulled
 Here's a `.gitlab-ci.yml` file showing how Docker caching can be used:
 
 ```yaml
-image: docker:19.03.11
+image: docker:19.03.12
 
 services:
-  - docker:19.03.11-dind
+  - docker:19.03.12-dind
 
 variables:
   # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index 2448bb536ab..735cf35584f 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -149,14 +149,14 @@ the job will fail:
 ```yaml
 job:
   services:
-  - php:7
-  - node:latest
-  - golang:1.10
+    - php:7
+    - node:latest
+    - golang:1.10
   image: alpine:3.7
   script:
-  - php -v
-  - node -v
-  - go version
+    - php -v
+    - node -v
+    - go version
 ```
 
 If you need to have `php`, `node` and `go` available for your script, you should
@@ -176,7 +176,7 @@ You can then use for example the [tutum/wordpress](https://hub.docker.com/r/tutu
 
 ```yaml
 services:
-- tutum/wordpress:latest
+  - tutum/wordpress:latest
 ```
 
 If you don't [specify a service alias](#available-settings-for-services),
@@ -219,7 +219,7 @@ default:
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 The image name must be in one of the following formats:
@@ -238,16 +238,16 @@ default:
 test:2.6:
   image: ruby:2.6
   services:
-  - postgres:11.7
+    - postgres:11.7
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 
 test:2.7:
   image: ruby:2.7
   services:
-  - postgres:12.2
+    - postgres:12.2
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 Or you can pass some [extended configuration options](#extended-docker-configuration-options)
@@ -260,17 +260,17 @@ default:
     entrypoint: ["/bin/bash"]
 
   services:
-  - name: my-postgres:11.7
-    alias: db-postgres
-    entrypoint: ["/usr/local/bin/db-postgres"]
-    command: ["start"]
+    - name: my-postgres:11.7
+      alias: db-postgres
+      entrypoint: ["/usr/local/bin/db-postgres"]
+      command: ["start"]
 
   before_script:
-  - bundle install
+    - bundle install
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 ## Passing environment variables to services
@@ -292,21 +292,21 @@ variables:
   POSTGRES_INITDB_ARGS: "--encoding=UTF8 --data-checksums"
 
 services:
-- name: postgres:11.7
-  alias: db
-  entrypoint: ["docker-entrypoint.sh"]
-  command: ["postgres"]
+  - name: postgres:11.7
+    alias: db
+    entrypoint: ["docker-entrypoint.sh"]
+    command: ["postgres"]
 
 image:
   name: ruby:2.6
   entrypoint: ["/bin/bash"]
 
 before_script:
-- bundle install
+  - bundle install
 
 test:
   script:
-  - bundle exec rake spec
+    - bundle exec rake spec
 ```
 
 ## Extended Docker configuration options
@@ -330,8 +330,8 @@ For example, the following two definitions are equal:
    image: "registry.example.com/my/image:latest"
 
    services:
-   - postgresql:9.4
-   - redis:latest
+     - postgresql:9.4
+     - redis:latest
    ```
 
 1. Using a map as an option to `image` and `services`. The use of `image:name` is
@@ -342,8 +342,8 @@ For example, the following two definitions are equal:
      name: "registry.example.com/my/image:latest"
 
    services:
-   - name: postgresql:9.4
-   - name: redis:latest
+     - name: postgresql:9.4
+     - name: redis:latest
    ```
 
 ### Available settings for `image`
@@ -378,8 +378,8 @@ would not work properly:
 
 ```yaml
 services:
-- mysql:latest
-- mysql:latest
+  - mysql:latest
+  - mysql:latest
 ```
 
 The Runner would start two containers using the `mysql:latest` image, but both
@@ -392,10 +392,10 @@ look like:
 
 ```yaml
 services:
-- name: mysql:latest
-  alias: mysql-1
-- name: mysql:latest
-  alias: mysql-2
+  - name: mysql:latest
+    alias: mysql-1
+  - name: mysql:latest
+    alias: mysql-2
 ```
 
 The Runner will still start two containers using the `mysql:latest` image,
@@ -427,7 +427,7 @@ CMD ["/usr/bin/super-sql", "run"]
 # .gitlab-ci.yml
 
 services:
-- my-super-sql:latest
+  - my-super-sql:latest
 ```
 
 After the new extended Docker configuration options, you can now simply
@@ -437,8 +437,8 @@ set a `command` in `.gitlab-ci.yml`, like:
 # .gitlab-ci.yml
 
 services:
-- name: super/sql:latest
-  command: ["/usr/bin/super-sql", "run"]
+  - name: super/sql:latest
+    command: ["/usr/bin/super-sql", "run"]
 ```
 
 As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https://docs.docker.com/engine/reference/builder/#cmd).
@@ -545,9 +545,8 @@ runtime.
   support for using private registries, which required manual configuration
   of credentials on runner's host. We recommend to upgrade your Runner to
   at least version **1.8** if you want to use private registries.
-- Not available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
-  follow <https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2673> for
-  details.
+- Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
+  in GitLab Runner 13.1 and later.
 
 ### Using statically-defined credentials
 
@@ -601,6 +600,7 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
   Open a terminal and execute the following command:
 
   ```shell
+  # Note the use of "-n" - it prevents encoding a newline in the password.
   echo -n "my_username:my_password" | base64
 
   # Example output to copy
@@ -681,11 +681,13 @@ To add `DOCKER_AUTH_CONFIG` to a Runner:
 
 1. Restart the Runner service.
 
-NOTE: **Note:** The double quotes included in the `DOCKER_AUTH_CONFIG`
+NOTE: **Note:**
+The double quotes included in the `DOCKER_AUTH_CONFIG`
 data must be escaped with backslashes. This prevents them from being
 interpreted as TOML.
 
-NOTE: **Note:** The `environment` option is a list. So your Runner may
+NOTE: **Note:**
+The `environment` option is a list. So your Runner may
 have existing entries and you should add this to the list, not replace
 it.
 
@@ -715,7 +717,8 @@ To configure credentials store, follow these steps:
      `${GITLAB_RUNNER_HOME}/.docker/config.json`. GitLab Runner will read this configuration file
      and will use the needed helper for this specific repository.
 
-NOTE: **Note:** `credsStore` is used to access ALL the registries.
+NOTE: **Note:**
+`credsStore` is used to access ALL the registries.
 If you will want to use both images from private registry and public images from DockerHub,
 pulling from DockerHub will fail, because Docker daemon will try to use the same credentials for **ALL** the registries.
 
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index d53430400ec..1580080ac6e 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -90,7 +90,7 @@ store:
     - |
       echo "-----BEGIN CERTIFICATE-----
       ...
-      -----END CERTIFICATE-----" >> /kaniko/ssl/certs/ca-certificates.crt
+      -----END CERTIFICATE-----" >> /kaniko/ssl/certs/additional-ca-cert-bundle.crt
 ```
 
 ## Video walkthrough of a working example