Fix whitespace that caused short-format in generated YAML

If the markdown contains trailing spaces, or has tabs included,
the YAML generator uses a compact format for the text (using `\n`
and `\t`, instead of plain newlines).

The compact format makes it difficult to review changes in the
yaml docs when vendoring in the documentation repository.

This patch:

- removes trailing whitespace
- replaces tabs for spaces
- fixes some minor formatting and markdown issues

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit f912deeec7fcabfba2d6c833854275231bf746cd)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 9fd323afdcec35e57272a4bafb882f71a2b39e0f
Component: cli

Author: thaJeztah

components/cli/docs/reference/commandline/build.md

@@ -49,7 +49,7 @@ Options:
       --no-cache                Do not use cache when building the image
   -o, --output                  Output destination (format: type=local,dest=path)
       --pull                    Always attempt to pull a newer version of the image
-      --progress                Set type of progress output (only if BuildKit enabled) (auto, plain, tty). 
+      --progress                Set type of progress output (only if BuildKit enabled) (auto, plain, tty).
                                 Use plain to show container output
   -q, --quiet                   Suppress the build output and print image ID on success
       --rm                      Remove intermediate containers after a successful build (default true)
@@ -431,7 +431,7 @@ $ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PRO
 This flag allows you to pass the build-time variables that are
 accessed like regular environment variables in the `RUN` instruction of the
 Dockerfile. Also, these values don't persist in the intermediate or final images
-like `ENV` values do.   You must add `--build-arg` for each build argument.  
+like `ENV` values do.   You must add `--build-arg` for each build argument.
 
 Using this flag will not alter the output you see when the `ARG` lines from the
 Dockerfile are echoed during the build process.
@@ -533,7 +533,7 @@ path):
 $ docker build --output type=local,dest=out .
 ```
 
-Use the `tar` type to export the files as a `.tar` archive: 
+Use the `tar` type to export the files as a `.tar` archive:
 
 ```bash
 $ docker build --output type=tar,dest=out.tar .

components/cli/docs/reference/commandline/dockerd.md

@@ -821,7 +821,7 @@ C:\> dockerd --storage-opt size=40G
 
 ##### `lcow.globalmode`
 
-Specifies whether the daemon instantiates utility VM instances as required 
+Specifies whether the daemon instantiates utility VM instances as required
 (recommended and default if omitted), or uses single global utility VM (better
 performance, but has security implications and not recommended for production
 deployments).
@@ -1071,7 +1071,7 @@ system's list of trusted CAs instead of enabling `--insecure-registry`.
 
 #### Legacy Registries
 
-Starting with Docker 17.12, operations against registries supporting only the 
+Starting with Docker 17.12, operations against registries supporting only the
 legacy v1 protocol are no longer supported. Specifically, the daemon will not
 attempt `push`, `pull` and `login` to v1 registries. The exception to this is
 `search` which can still be performed on v1 registries.
@@ -1446,8 +1446,8 @@ This is a full example of the allowed configuration options on Windows:
 ```
 
 #### Feature options
-The optional field `features` in `daemon.json` allows users to enable or disable specific 
-daemon features. For example, `{"features":{"buildkit": true}}` enables `buildkit` as the 
+The optional field `features` in `daemon.json` allows users to enable or disable specific
+daemon features. For example, `{"features":{"buildkit": true}}` enables `buildkit` as the
 default docker image builder.
 
 The list of currently supported feature options:

components/cli/docs/reference/commandline/events.md

@@ -31,11 +31,11 @@ Options:
 ## Description
 
 Use `docker events` to get real-time events from the server. These events differ
-per Docker object type. Different event types have different scopes. Local 
-scoped events are only seen on the node they take place on, and swarm scoped 
+per Docker object type. Different event types have different scopes. Local
+scoped events are only seen on the node they take place on, and swarm scoped
 events are seen on all managers.
 
-Only the last 1000 log events are returned. You can use filters to further limit 
+Only the last 1000 log events are returned. You can use filters to further limit
 the number of events returned.
 
 ### Object types
@@ -165,7 +165,7 @@ that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
 seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
 fraction of a second no more than nine digits long.
 
-Only the last 1000 log events are returned. You can use filters to further limit 
+Only the last 1000 log events are returned. You can use filters to further limit
 the number of events returned.
 
 #### Filtering
@@ -207,7 +207,7 @@ format. Go's [text/template](http://golang.org/pkg/text/template/) package
 describes all the details of the format.
 
 If a format is set to `{{json .}}`, the events are streamed as valid JSON
-Lines. For information about JSON Lines, please refer to http://jsonlines.org/ .
+Lines. For information about JSON Lines, please refer to http://jsonlines.org/.
 
 ## Examples
 
@@ -410,12 +410,12 @@ Type=container  Status=destroy  ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299
 
 #### Format as JSON
 
-```none
-    $ docker events --format '{{json .}}'
+```bash
+$ docker events --format '{{json .}}'
 
-    {"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
-    {"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
-    {"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e..
-    {"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42..
-    {"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
+{"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
+{"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
+{"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e..
+{"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42..
+{"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
 ```

components/cli/docs/reference/commandline/exec.md

@@ -29,7 +29,7 @@ Options:
       --privileged     Give extended privileges to the command
   -t, --tty            Allocate a pseudo-TTY
   -u, --user           Username or UID (format: <name|uid>[:<group|gid>])
-  -w, --workdir        Working directory inside the container  
+  -w, --workdir        Working directory inside the container
 ```
 
 ## Description
@@ -83,8 +83,8 @@ Next, set an environment variable in the current bash session.
 $ docker exec -it -e VAR=1 ubuntu_bash bash
 ```
 
-This will create a new Bash session in the container `ubuntu_bash` with environment 
-variable `$VAR` set to "1". Note that this environment variable will only be valid 
+This will create a new Bash session in the container `ubuntu_bash` with environment
+variable `$VAR` set to "1". Note that this environment variable will only be valid
 on the current Bash session.
 
 By default `docker exec` command runs in the same working directory set when container was created.

components/cli/docs/reference/commandline/info.md

@@ -106,7 +106,7 @@ Server:
   myinsecurehost:5000
   127.0.0.0/8
 ```
- 
+
 ### Show debugging output
 
 Here is a sample output for a daemon running on Ubuntu, using the overlay2

components/cli/docs/reference/commandline/login.md

@@ -32,6 +32,8 @@ Options:
 
 Login to a registry.
 
+## Examples
+
 ### Login to a self-hosted registry
 
 If you want to login to a self-hosted registry you can specify this by
@@ -94,7 +96,7 @@ For example, to use `docker-credential-osxkeychain`:
 
 ```json
 {
-	"credsStore": "osxkeychain"
+  "credsStore": "osxkeychain"
 }
 ```
 
@@ -124,9 +126,9 @@ or an identity token.
 
 ```json
 {
-	"ServerURL": "https://index.docker.io/v1",
-	"Username": "david",
-	"Secret": "passw0rd1"
+  "ServerURL": "https://index.docker.io/v1",
+  "Username": "david",
+  "Secret": "passw0rd1"
 }
 ```
 
@@ -145,8 +147,8 @@ and password from this payload:
 
 ```json
 {
-	"Username": "david",
-	"Secret": "passw0rd1"
+  "Username": "david",
+  "Secret": "passw0rd1"
 }
 ```
 

components/cli/docs/reference/commandline/manifest.md

@@ -43,8 +43,8 @@ more (ideally more than one) image names. It can then be used in the same way as
 an image name in `docker pull` and `docker run` commands, for example.
 
 Ideally a manifest list is created from images that are identical in function for
-different os/arch combinations. For this reason, manifest lists are often referred to as
-"multi-arch images". However, a user could create a manifest list that points
+different os/arch combinations. For this reason, manifest lists are often referred
+to as "multi-arch images". However, a user could create a manifest list that points
 to two images -- one for windows on amd64, and one for darwin on amd64.
 
 ### manifest inspect
@@ -62,7 +62,7 @@ Options:
   -v, --verbose    Output additional info including layers and platform
 ```
 
-### manifest create 
+### manifest create
 
 ```bash
 Usage:  docker manifest create MANIFEST_LIST MANIFEST [MANIFEST...]
@@ -76,6 +76,7 @@ Options:
 ```
 
 ### manifest annotate
+
 ```bash
 Usage:  docker manifest annotate [OPTIONS] MANIFEST_LIST MANIFEST
 
@@ -91,6 +92,7 @@ Options:
 ```
 
 ### manifest push
+
 ```bash
 Usage:  docker manifest push [OPTIONS] MANIFEST_LIST
 
@@ -104,12 +106,21 @@ Options:
 
 ### Working with insecure registries
 
-The manifest command interacts solely with a Docker registry. Because of this, it has no way to query the engine for the list of allowed insecure registries. To allow the CLI to interact with an insecure registry, some `docker manifest` commands have an `--insecure` flag. For each transaction, such as a `create`, which queries a registry, the `--insecure` flag must be specified. This flag tells the CLI that this registry call may ignore security concerns like missing or self-signed certificates. Likewise, on a `manifest push` to an insecure registry, the `--insecure` flag must be specified. If this is not used with an insecure registry, the manifest command fails to find a registry that meets the default requirements.
+The manifest command interacts solely with a Docker registry. Because of this,
+it has no way to query the engine for the list of allowed insecure registries.
+To allow the CLI to interact with an insecure registry, some `docker manifest`
+commands have an `--insecure` flag. For each transaction, such as a `create`,
+which queries a registry, the `--insecure` flag must be specified. This flag
+tells the CLI that this registry call may ignore security concerns like missing
+or self-signed certificates. Likewise, on a `manifest push` to an insecure
+registry, the `--insecure` flag must be specified. If this is not used with an
+insecure registry, the manifest command fails to find a registry that meets the
+default requirements.
 
 ## Examples
 
 ### Inspect an image's manifest object
- 
+
 ```bash
 $ docker manifest inspect hello-world
 {
@@ -136,7 +147,7 @@ The `docker manifest inspect` command takes an optional `--verbose` flag
 that gives you the image's name (Ref), and architecture and os (Platform).
 
 Just as with other docker commands that take image names, you can refer to an image with or
-without a tag, or by digest (e.g. hello-world@sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f).
+without a tag, or by digest (e.g. `hello-world@sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f`).
 
 Here is an example of inspecting an image's manifest with the `--verbose` flag:
 
@@ -170,24 +181,27 @@ $ docker manifest inspect --verbose hello-world
 
 ### Create and push a manifest list
 
-To create a manifest list, you first `create` the manifest list locally by specifying the constituent images you would
-like to have included in your manifest list. Keep in mind that this is pushed to a registry, so if you want to push
-to a registry other than the docker registry, you need to create your manifest list with the registry name or IP and port.
+To create a manifest list, you first `create` the manifest list locally by
+specifying the constituent images you would like to have included in your
+manifest list. Keep in mind that this is pushed to a registry, so if you want to
+push to a registry other than the docker registry, you need to create your
+manifest list with the registry name or IP and port.
 This is similar to tagging an image and pushing it to a foreign registry.
 
 After you have created your local copy of the manifest list, you may optionally
-`annotate` it. Annotations allowed are the architecture and operating system (overriding the image's current values),
-os features, and an architecture variant. 
+`annotate` it. Annotations allowed are the architecture and operating system
+(overriding the image's current values), os features, and an architecture variant.
 
-Finally, you need to `push` your manifest list to the desired registry. Below are descriptions of these three commands,
-and an example putting them all together.
+Finally, you need to `push` your manifest list to the desired registry. Below are
+descriptions of these three commands, and an example putting them all together.
 
 ```bash
 $ docker manifest create 45.55.81.106:5000/coolapp:v1 \
     45.55.81.106:5000/coolapp-ppc64le-linux:v1 \
     45.55.81.106:5000/coolapp-arm-linux:v1 \
     45.55.81.106:5000/coolapp-amd64-linux:v1 \
     45.55.81.106:5000/coolapp-amd64-windows:v1
+
 Created manifest list 45.55.81.106:5000/coolapp:v1
 ```
 
@@ -255,20 +269,24 @@ $ docker manifest inspect coolapp:v1
 
 ### Push to an insecure registry
 
-Here is an example of creating and pushing a manifest list using a known insecure registry.
+Here is an example of creating and pushing a manifest list using a known
+insecure registry.
 
-```
+```bash
 $ docker manifest create --insecure myprivateregistry.mycompany.com/repo/image:1.0 \
     myprivateregistry.mycompany.com/repo/image-linux-ppc64le:1.0 \
     myprivateregistry.mycompany.com/repo/image-linux-s390x:1.0 \
     myprivateregistry.mycompany.com/repo/image-linux-arm:1.0 \
     myprivateregistry.mycompany.com/repo/image-linux-armhf:1.0 \
     myprivateregistry.mycompany.com/repo/image-windows-amd64:1.0 \
     myprivateregistry.mycompany.com/repo/image-linux-amd64:1.0
-```
-```
+
 $ docker manifest push --insecure myprivateregistry.mycompany.com/repo/image:tag
 ```
 
-Note that the `--insecure` flag is not required to annotate a manifest list, since annotations are to a locally-stored copy of a manifest list. You may also skip the `--insecure` flag if you are performing a `docker manifest inspect` on a locally-stored manifest list. Be sure to keep in mind that locally-stored manifest lists are never used by the engine on a `docker pull`.
+> **Note**: the `--insecure` flag is not required to annotate a manifest list,
+> since annotations are to a locally-stored copy of a manifest list. You may also
+> skip the `--insecure` flag if you are performing a `docker manifest inspect`
+> on a locally-stored manifest list. Be sure to keep in mind that locally-stored
+> manifest lists are never used by the engine on a `docker pull`.
 

components/cli/docs/reference/commandline/network_ls.md

@@ -192,7 +192,7 @@ The following filter matches all user defined networks:
 ```bash
 $ docker network ls --filter type=custom
 NETWORK ID          NAME                DRIVER       SCOPE
-95e74588f40d        foo                 bridge       local  
+95e74588f40d        foo                 bridge       local
 63d1ff1f77b0        dev                 bridge       local
 ```