Fix all markdownlint issues

site/content/en/concepts/architecture/_index.md

@@ -42,7 +42,7 @@ We do this by keeping resources serialized as either JSON or YAML configuration.
 
 - [link](https://changelog.com/gotime/114#t=00:12:09.18)
 
-#### kpt vs kubernetes:
+#### kpt vs kubernetes
 
 - While the Kubernetes control-plane reads / writes configuration data stored by the apiserver
   (e.g. in etcd or some other database), kpt reads / writes configuration data stored as local
@@ -105,7 +105,7 @@ Additionally, kpt offers *functions* as an extension mechanism to simplify publi
 and to provide deeper integration with kpt -- e.g. invoking functions automatically
 after kpt commands.
 
-#### kpt vs kubernetes:
+#### kpt vs kubernetes
 
 - kpt: resource configuration is read, modified and written back to its source (or another destination)
   - resources may be updated using 3-way merge (kpt pkg update)
@@ -127,7 +127,7 @@ generating and transforming it given some context.
 Since all tools read and write configuration data, multiple tools may be composed by
 invoking them against the same configuration data and pipelining their commands.
 
-#### kpt vs kubernetes:
+#### kpt vs kubernetes
 
 - kpt:
   - read / write files, http, ...
@@ -156,7 +156,7 @@ changes to the tool itself.
   that specific instance
   - e.g. an nginx Deployment's `image` may be restricted to the regular expression `^nginx:.*$`
 
-#### kpt vs kubernetes:
+#### kpt vs kubernetes
 
 - kpt: OpenAPI read from multiple sources -- can also be inlined into individual
   configuration objects as comments

site/content/en/concepts/packaging/_index.md

@@ -24,4 +24,4 @@ In order to facilitate programmatic operations, kpt:
 For compatibility with other arbitrary formats, kpt supports generating
 resource configuration data from templates, configuration DSLs, and programs using [source functions].
 
-[source functions]: ../functions/#source-function
+[source functions]: ../functions/#source-function

site/content/en/guides/consumer/substitute/_index.md

@@ -110,7 +110,7 @@ kpt cfg list-setters helloworld/ --include-subst
   http-port   80      package-default   helloworld port         3
   image-tag   0.1.0   package-default   hello-world image tag   1
   replicas    5       package-default   helloworld replicas     1
-  ------------   ------------------------------------------   ----------                  
+  ------------   ------------------------------------------   ----------
   SUBSTITUTION                    PATTERN                     REFERENCES
   image          gcr.io/kpt-dev/helloworld-gke:${image-tag}   [image-tag]
 ```

site/content/en/guides/ecosystem/helm/_index.md

@@ -13,7 +13,6 @@ description: >
 Helm charts may be used to generate kpt packages which can then be further
 customized directly.
 
-
 ## Steps
 
 1. [Fetch a Helm chart](#fetch-a-helm-chart)
@@ -56,7 +55,7 @@ wrote ./mysql/templates/deployment.yaml
 ##### Command
 
 ```sh
-$ tree mysql/
+tree mysql/
 ```
 
 ##### Output

site/content/en/guides/producer/_index.md

@@ -7,8 +7,9 @@ description: >
     Guides for publishing configuration packages for others to consume.
 ---
 {{% pageinfo color="warning" %}}
+
 # Notice: Under Development
-{{% /pageinfo %}}
 
+{{% /pageinfo %}}
 
 {{< svg src="images/producer-guide" >}}

site/content/en/guides/producer/init/_index.md

@@ -23,7 +23,7 @@ Packages may be nested -- both parent (composite) and child
 A package is versioned by tagging the git repo as one of:
 
 - `package-subdirectory/package-version` (directory scoped versioning)
--  `package-version` (repo scoped versioning)
+- `package-version` (repo scoped versioning)
 {{% /pageinfo %}}
 
 {{< svg src="images/producer-guide" >}}
@@ -35,7 +35,6 @@ A package is versioned by tagging the git repo as one of:
 2. [Create configuration](#create-configuration)
 3. [Publish package to git](#publish-package-to-git)
 
-
 ## Create a git repo
 
 ```sh
@@ -58,7 +57,7 @@ kpt pkg init nginx --tag kpt.dev/app=nginx --description "kpt nginx package"
 ## Create configuration
 
 ```sh
-$ curl https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/controllers/nginx-deployment.yaml --output nginx/nginx-deployment.yaml
+curl https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/controllers/nginx-deployment.yaml --output nginx/nginx-deployment.yaml
 ```
 
 ## Publish package to git

site/content/en/guides/producer/setters/_index.md

@@ -117,11 +117,12 @@ spec:
 ```
 
 #### OpenAPI Validations
+
 Users can input any additional validation constraints during `create-setter`
 operation in the form of openAPI schema. Relevant openAPI specification
 constraints can be provided in json file format. The `set` operation validates
 the input value against provided schema during setter creation and throws an
-error if the input value doesn't meet any of the constraints. 
+error if the input value doesn't meet any of the constraints.
 
 ```sh
 $ cat /path/to/file.json
@@ -351,7 +352,7 @@ openAPI:
 ```
 
 ```sh
-# if you live apply/preview without setting the value 
+# if you live apply/preview without setting the value
 kpt live apply hello-world/
 
 error: setter replicas is required but not set, please set it and try again
@@ -365,19 +366,17 @@ kpt live apply hello-world/
 # Success
 ```
 
-
-
 #### Modifying a Setter
 
-Setters are uniquely identified by their name. create-setter command can be leveraged 
+Setters are uniquely identified by their name. create-setter command can be leveraged
 to modify an existing setter definition. Users may choose to modify setters in following
 scenarios.
 
 1. Add new features to existing setters, such as openAPI validations, marking setter
 as required setter etc.
-2. Add existing setter references to new resources that are added to package. 
+2. Add existing setter references to new resources that are added to package.
 
-Consider an existing package with deployment-foo.yaml and Kptfile as follows. 
+Consider an existing package with deployment-foo.yaml and Kptfile as follows.
 
 ```yaml
 # deployment-foo.yaml
@@ -483,6 +482,7 @@ spec:
 # delete a setter named "replicas"
 kpt cfg delete-setter replicas
 ```
+
 ```yaml
 # Kptfile -- updated
 openAPI:
@@ -494,7 +494,7 @@ kind: Deployment
 metadata:
   name: foo
 spec:
-  replicas: 3 
+  replicas: 3
 ```
 
-[OpenAPI types]: https://swagger.io/docs/specification/data-models/data-types/
+[OpenAPI types]: https://swagger.io/docs/specification/data-models/data-types/

site/content/en/guides/producer/variant/_index.md

@@ -8,5 +8,7 @@ description: >
 ---
 
 {{% pageinfo color="warning" %}}
+
 # Notice: Under Development
+
 {{% /pageinfo %}}

site/content/en/installation/binaries/_index.md

@@ -9,11 +9,11 @@ description: >
 
 Download pre-compiled binaries.
 
-| Platform                 
-| ------------------------ 
-| [Linux (x64)][linux]     
-| [macOS (x64)][darwin]    
-| [Windows (x64)][windows] 
+| Platform
+| ------------------------
+| [Linux (x64)][linux]
+| [macOS (x64)][darwin]
+| [Windows (x64)][windows]
 
 ```sh
 # For linux/mac

site/content/en/reference/cfg/annotate/_index.md

@@ -47,12 +47,14 @@ kpt cfg annotate DIR --kv KEY=VALUE...
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory
 ```
 
 #### Flags
+
 ```
 --apiVersion
   Only set annotations on resources with this apiVersion.

site/content/en/reference/cfg/grep/_index.md

@@ -49,6 +49,7 @@ kpt cfg grep QUERY DIR
 ```
 
 #### Args
+
 ```
     QUERY:
       Query to match expressed as 'path.to.field=value'.
@@ -62,6 +63,7 @@ kpt cfg grep QUERY DIR
 ```
 
 #### Flags
+
 ```
     --invert-match, -v
       keep resources NOT matching the specified pattern

site/content/en/reference/cfg/tree/_index.md

@@ -74,12 +74,14 @@ kpt cfg tree [DIR] [flags]
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory.  Defaults to STDIN if not specified.
 ```
 
 #### Flags
+
 ```
 --args:
   if true, print the container args field

site/content/en/reference/live/apply/_index.md

@@ -62,7 +62,6 @@ config-map-2 (ConfigMap)
 When the updated package is applied, `config-map-1` is automatically
 deleted (pruned) since it is omitted.
 
-
 In order to take advantage of this automatic clean-up, a package must contain
 a **grouping object template**, which is a ConfigMap with a special label. An example is:
 
@@ -94,7 +93,7 @@ test-grouping-object-17b4dba8
 
 ### Status (reconcile-timeout=<DURATION>)
 
-kpt live apply also has support for computing status for resources. This is 
+kpt live apply also has support for computing status for resources. This is
 useful during apply for making sure that not only are the set of resources applied
 into the cluster, but also that the desired state expressed in the resource are
 fully reconciled in the cluster. An example of this could be applying a deployment. Without
@@ -106,12 +105,13 @@ Status is computed through a set of rules for the built-in types, and
 functionality for polling a set of resources and computing the aggregate status
 for the set. For CRDs, the status computation make a set of assumptions about
 the fields in the status object of the resource and the conditions that
-are set by the custom controller. If CRDs follow the recommendations below, 
+are set by the custom controller. If CRDs follow the recommendations below,
 kpt live apply will be able to correctly compute status
 
 #### Recommendations for CRDs
+
 The custom controller should use the following conditions to signal whether
-a resource has been fully reconciled, and whether it has encountered any 
+a resource has been fully reconciled, and whether it has encountered any
 problems:
 
 **Reconciling**: Indicates that the resource does not yet match its spec. i.e.
@@ -131,16 +131,16 @@ retry forever, so this should not be considered a terminal state.
 
 These conditions adhere to the [Kubernetes design principles]
 which include expressing conditions using abnormal-true polarity. There is
-currently a [proposal] to change to guidance for conditions. If this is 
-accepted, the recommended conditions for kpt might also change, but we will 
+currently a [proposal] to change to guidance for conditions. If this is
+accepted, the recommended conditions for kpt might also change, but we will
 continue to support the current set of conditions.
 
-CRDs should also set the `observedGeneration` field in the status object, a 
+CRDs should also set the `observedGeneration` field in the status object, a
 pattern already common in the built-in types. The controller should update
 this field every time it sees a new generation of the resource. This allows
 the kpt library to distinguish between resources that do not have any
 conditions set because they are fully reconciled, from resources that have no
-conditions set because they have just been created. 
+conditions set because they have just been created.
 
 An example of a resource where the latest change has been observed by
 the controller which is currently in the process of reconciling would be:
@@ -168,8 +168,8 @@ status:
     type: Stalled
 ```
 
-The status for this resource state will be InProgress. So if the 
-`--reconcile-timeout` flag is set, kpt live apply will wait until 
+The status for this resource state will be InProgress. So if the
+`--reconcile-timeout` flag is set, kpt live apply will wait until
 the `Reconciling` condition is `False` before pruning and exiting.
 
 ### Examples
@@ -197,16 +197,18 @@ kpt live apply DIR [flags]
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory.  The directory must contain exactly
   one ConfigMap with the grouping object annotation.
 ```
 
-#### Flags:
+#### Flags
+
 ```
 --poll-period:
-  The frequency with which the cluster will be polled to determine 
+  The frequency with which the cluster will be polled to determine
   the status of the applied resources. The default value is every 2 seconds.
 
 --reconcile-timeout:
@@ -215,18 +217,18 @@ DIR:
   resources to reconcile.
 
 --prune-timeout:
-  The threshold for how long to wait for all pruned resources to be 
+  The threshold for how long to wait for all pruned resources to be
   deleted before giving up. If this flag is not set, kpt live apply will not
-  wait. In most cases, it would also make sense to set the 
+  wait. In most cases, it would also make sense to set the
   --prune-propagation-policy to Foreground when this flag is set.
 
 --prune-propagation-policy:
   The propagation policy kpt live apply should use when pruning resources. The
   default value here is Background. The other options are Foreground and Orphan.
 
 --output:
-  This determines the output format of the command. The default value is 
-  events, which will print the events as they happen. The other option is 
+  This determines the output format of the command. The default value is
+  events, which will print the events as they happen. The other option is
   table, which will show the output in a table format.
 ```
 <!--mdtogo-->

site/content/en/reference/live/destroy/_index.md

@@ -28,6 +28,7 @@ kpt live destroy DIR
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory.  The directory must contain exactly

site/content/en/reference/live/diff/_index.md

@@ -35,12 +35,14 @@ available in your path will be run with "-u" (unicode) and "-N" (treat new files
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory.  The directory must contain exactly one ConfigMap with the inventory annotation.
 ```
 
 #### Exit Status
+
 ```
 The following exit values shall be returned:
 

site/content/en/reference/live/fetch-k8s-schema/_index.md

@@ -30,6 +30,7 @@ kpt live fetch-k8s-schema [flags]
 ```
 
 #### Flags
+
 ```
 --pretty-print
   Format the output before printing

site/content/en/reference/live/init/_index.md

@@ -38,13 +38,15 @@ kpt live init DIRECTORY [flags]
 ```
 
 #### Args
+
 ```
 DIR:
   Path to a package directory.  The directory must contain exactly
   one ConfigMap with the grouping object annotation.
 ```
 
 #### Flags
+
 ```
 --group-name:
   String name to group applied resources. Must be composed of valid