chore: fix markdown linting

* without `-print0` / `-0`, paths with spaces were skipped sometimes;
* `--stdin-filename` flag incorrectly consumed the first file.

Signed-off-by: Alexey Palazhchenko <[email protected]>

.dockerignore

@@ -9,6 +9,7 @@
 !website
 !.golangci.yml
 !.markdownlint.json
+!.textlintrc.json
 !go.mod
 !go.sum
 !prototool.yaml

.textlintrc.json

@@ -0,0 +1,8 @@
+{
+  "rules": {
+    "one-sentence-per-line": true
+  },
+  "filters": {
+    "comments": true
+  }
+}

Dockerfile

@@ -606,6 +606,7 @@ FROM node:16.1.0-alpine AS lint-markdown
 RUN apk add --no-cache findutils
 RUN npm i -g [email protected]
 RUN npm i -g [email protected]
+RUN npm i -g [email protected]
 RUN npm i -g [email protected]
 WORKDIR /src
 COPY . .
@@ -615,7 +616,8 @@ RUN markdownlint \
     --ignore '**/CODE_OF_CONDUCT.md' \
     --ignore '**/node_modules/**' \
     --ignore '**/hack/chglog/**' \
-    --ignore 'website/content/docs/*/Reference/*' .
+    --ignore 'website/content/docs/*/Reference/*' \
+    .
 RUN find . \
     -name '*.md' \
     -not -path './LICENCE.md' \
@@ -624,7 +626,8 @@ RUN find . \
     -not -path '*/node_modules/*' \
     -not -path './hack/chglog/**' \
     -not -path './website/content/docs/*/Reference/*' \
-    | xargs textlint --rule one-sentence-per-line --stdin-filename
+    -print0 \
+    | xargs -0 textlint
 
 # The docs target generates documentation.
 

README.md

@@ -1,4 +1,4 @@
-<!-- markdownlint-disable MD041 MD034 -->
+<!-- markdownlint-disable MD041 -->
 
 <p align="center">
   <h1 align="center">Talos</h1>

website/content/docs/v0.10/Bare Metal Platforms/equinix-metal.md

@@ -27,10 +27,14 @@ The following is a list of kernel parameters required by Talos:
 
 ### User Data
 
+<!-- textlint-disable one-sentence-per-line -->
+
 To configure a Talos you can use the metadata service provide by Equinix Metal.
 It is required to add a shebang to the top of the configuration file.
 The shebang is arbitrary in the case of Talos, and the convention we use is `#!talos`.
 
+<!-- textlint-disable one-sentence-per-line -->
+
 ## Creating a Cluster via the Equinix Metal CLI
 
 ### Control Plane Endpoint

website/content/docs/v0.10/Cloud Platforms/digitalocean.md

@@ -11,8 +11,8 @@ If you need more information on DigitalOcean specifics, please see the [official
 
 ### Create the Image
 
-First, download the DigitalOcean image from a Talos release. Extract the archive to get the `disk.raw` file, compress it using
-`gzip` to `disk.raw.gz`.
+First, download the DigitalOcean image from a Talos release.
+Extract the archive to get the `disk.raw` file, compress it using `gzip` to `disk.raw.gz`.
 
 Using an upload method of your choice (`doctl` does not have Spaces support), upload the image to a space.
 Now, create an image using the URL of the uploaded image:

website/content/docs/v0.10/Learn More/control-plane.md

@@ -9,7 +9,8 @@ This guide provides details on how Talos runs and bootstraps the Kubernetes cont
 
 Talos cluster bootstrap flow:
 
-1. The `etcd` service is started on control plane nodes. Instances of `etcd` on control plane nodes build the `etcd` cluster.
+1. The `etcd` service is started on control plane nodes.
+   Instances of `etcd` on control plane nodes build the `etcd` cluster.
 2. The `kubelet` service is started.
 3. Control plane components are started as static pods via the `kubelet`, and the `kube-apiserver` component connects to the local (running on the same node) `etcd` instance.
 4. The `kubelet` issues client certificate using the bootstrap token using the control plane endpoint (via `kube-apiserver` and `kube-controller-manager`).

website/content/docs/v0.10/Learn More/controllers-resources.md

@@ -5,46 +5,42 @@ weight: 9
 
 <!-- markdownlint-disable MD038 -->
 
-Talos implements concepts of *resources* and *controllers* to facilitate internal operations of the
-operating system. Talos resources and controllers are very similar to Kubernetes resources and controllers,
-but there are some differences. The content of this document is not required to operate Talos, but it is
-useful for troubleshooting.
+Talos implements concepts of *resources* and *controllers* to facilitate internal operations of the operating system.
+Talos resources and controllers are very similar to Kubernetes resources and controllers, but there are some differences.
+The content of this document is not required to operate Talos, but it is useful for troubleshooting.
 
-Starting with Talos 0.9, most of the Kubernetes control plane boostrapping and operations is implemented
-via controllers and resources which allows Talos to be reactive to configuration changes, environment
-changes (e.g. time sync).
+Starting with Talos 0.9, most of the Kubernetes control plane boostrapping and operations is implemented via controllers and resources which allows Talos to be reactive to configuration changes, environment changes (e.g. time sync).
 
 ## Resources
 
-A resource captures a piece of system state. Each resource belongs to a "Type" which defines resource contents.
+A resource captures a piece of system state.
+Each resource belongs to a "Type" which defines resource contents.
 Resource state can be split in two parts:
 
 * metadata: fixed set of fields describing resource - namespace, type, ID, etc.
 * spec: contents of the resource (depends on resource type).
 
-Resource is uniquely identified by (`namespace`, `type`, `id`). Namespaces provide a way to avoid conflicts on
-duplicate resource IDs.
+Resource is uniquely identified by (`namespace`, `type`, `id`).
+Namespaces provide a way to avoid conflicts on duplicate resource IDs.
 
-At the moment of this writing, all resources are local to the node and stored in memory. So on every reboot
-resource state is rebuilt from scratch (the only exception is `MachineConfig` resource which reflects current
-machine config).
+At the moment of this writing, all resources are local to the node and stored in memory.
+So on every reboot resource state is rebuilt from scratch (the only exception is `MachineConfig` resource which reflects current machine config).
 
 ## Controllers
 
-Controllers run as independent lightweight threads in Talos. The goal of the controller is to reconcile
-the state based on inputs and eventually update outputs.
+Controllers run as independent lightweight threads in Talos.
+The goal of the controller is to reconcile the state based on inputs and eventually update outputs.
 
-A controller can have any number of resource types (and namespaces) as inputs. In other words, it watches
-specified resources for changes and reconciles when these changes occur. A controller might also have additional
-inputs: running reconcile on schedule, watching `etcd` keys, etc.
+A controller can have any number of resource types (and namespaces) as inputs.
+In other words, it watches specified resources for changes and reconciles when these changes occur.
+A controller might also have additional inputs: running reconcile on schedule, watching `etcd` keys, etc.
 
-A controller has a single output: a set of resources of fixed type in a fixed namespace. Only one controller
-can manage resource type in the namespace, so conflicts are avoided.
+A controller has a single output: a set of resources of fixed type in a fixed namespace.
+Only one controller can manage resource type in the namespace, so conflicts are avoided.
 
 ## Querying Resources
 
-Talos CLI tool `talosctl` provides read-only access to the resource API which includes getting specific resource,
-listing resources and watching for changes.
+Talos CLI tool `talosctl` provides read-only access to the resource API which includes getting specific resource, listing resources and watching for changes.
 
 Talos stores resources describing resource types and namespaces in `meta` namespace:
 
@@ -79,8 +75,7 @@ NODE         NAMESPACE   TYPE        ID             VERSION
 172.20.0.2   meta        Namespace   secrets        1
 ```
 
-Most of the time namespace flag (`--namespace`) can be omitted, as `ResourceDefinition` contains default
-namespace which is used if no namespace is given:
+Most of the time namespace flag (`--namespace`) can be omitted, as `ResourceDefinition` contains default namespace which is used if no namespace is given:
 
 ```bash
 $ talosctl get resourcedefinitions resourcedefinitions.meta.cosi.dev -o yaml
@@ -118,16 +113,15 @@ NODE         NAMESPACE   TYPE        ID             VERSION
 Command `talosctl get` supports following output modes:
 
 * `table` (default) prints resource list as a table
-* `yaml` prints pretty formatted resources with details, including full metadata spec. This format carries most
-  details from the backend resource (e.g. comments in `MachineConfig` resource)
+* `yaml` prints pretty formatted resources with details, including full metadata spec.
+  This format carries most details from the backend resource (e.g. comments in `MachineConfig` resource)
 * `json` prints same information as `yaml`, some additional details (e.g. comments) might be lost.
   This format is useful for automated processing with tools like `jq`.
 
 ### Watching Changes
 
-If flag `--watch` is appended to the `talosctl get` command, the command switches to watch mode. If list of resources
-was requested, `talosctl` prints initial contents of the list and then appends resource information
-for every change:
+If flag `--watch` is appended to the `talosctl get` command, the command switches to watch mode.
+If list of resources was requested, `talosctl` prints initial contents of the list and then appends resource information for every change:
 
 ```bash
 $ talosctl get svc -w

website/content/docs/v0.10/Learn More/faqs.md

@@ -16,13 +16,16 @@ It's a big change from how operating systems have been managed in the past, but
 
 ## Why no shell or SSH?
 
-Since Talos is fully API-driven, all maintenance and debugging operations should be possible via the OS API. We would like for Talos users to start thinking about what a "machine" is in the context of a Kubernetes cluster.
+Since Talos is fully API-driven, all maintenance and debugging operations should be possible via the OS API.
+We would like for Talos users to start thinking about what a "machine" is in the context of a Kubernetes cluster.
 That is, that a Kubernetes _cluster_ can be thought of as one massive machine, and the _nodes_ are merely additional, undifferentiated resources.
 We don't want humans to focus on the _nodes_, but rather on the _machine_ that is the Kubernetes cluster.
-Should an issue arise at the node level, `talosctl` should provide the necessary tooling to assist in the identification, debugging, and remedation of the issue. However, the API is based on the Principle of Least Privilege, and exposes only a limited set of methods.
+Should an issue arise at the node level, `talosctl` should provide the necessary tooling to assist in the identification, debugging, and remedation of the issue.
+However, the API is based on the Principle of Least Privilege, and exposes only a limited set of methods.
 We envision Talos being a great place for the application of [control theory](https://en.wikipedia.org/wiki/Control_theory) in order to provide a self-healing platform.
 
 ## Why the name "Talos"?
 
 Talos was an automaton created by the Greek God of the forge to protect the island of Crete.
-He would patrol the coast and enforce laws throughout the land. We felt it was a fitting name for a security focused operating system designed to run Kubernetes.
+He would patrol the coast and enforce laws throughout the land.
+We felt it was a fitting name for a security focused operating system designed to run Kubernetes.

website/content/docs/v0.11/Bare Metal Platforms/equinix-metal.md

@@ -27,10 +27,14 @@ The following is a list of kernel parameters required by Talos:
 
 ### User Data
 
+<!-- textlint-disable one-sentence-per-line -->
+
 To configure a Talos you can use the metadata service provide by Equinix Metal.
 It is required to add a shebang to the top of the configuration file.
 The shebang is arbitrary in the case of Talos, and the convention we use is `#!talos`.
 
+<!-- textlint-enable one-sentence-per-line -->
+
 ## Creating a Cluster via the Equinix Metal CLI
 
 ### Control Plane Endpoint

website/content/docs/v0.11/Cloud Platforms/digitalocean.md

@@ -11,8 +11,8 @@ If you need more information on DigitalOcean specifics, please see the [official
 
 ### Create the Image
 
-First, download the DigitalOcean image from a Talos release. Extract the archive to get the `disk.raw` file, compress it using
-`gzip` to `disk.raw.gz`.
+First, download the DigitalOcean image from a Talos release.
+Extract the archive to get the `disk.raw` file, compress it using `gzip` to `disk.raw.gz`.
 
 Using an upload method of your choice (`doctl` does not have Spaces support), upload the image to a space.
 Now, create an image using the URL of the uploaded image:

website/content/docs/v0.11/Learn More/control-plane.md

@@ -9,7 +9,8 @@ This guide provides details on how Talos runs and bootstraps the Kubernetes cont
 
 Talos cluster bootstrap flow:
 
-1. The `etcd` service is started on control plane nodes. Instances of `etcd` on control plane nodes build the `etcd` cluster.
+1. The `etcd` service is started on control plane nodes.
+   Instances of `etcd` on control plane nodes build the `etcd` cluster.
 2. The `kubelet` service is started.
 3. Control plane components are started as static pods via the `kubelet`, and the `kube-apiserver` component connects to the local (running on the same node) `etcd` instance.
 4. The `kubelet` issues client certificate using the bootstrap token using the control plane endpoint (via `kube-apiserver` and `kube-controller-manager`).

website/content/docs/v0.11/Learn More/controllers-resources.md

@@ -5,41 +5,38 @@ weight: 9
 
 <!-- markdownlint-disable MD038 -->
 
-Talos implements concepts of *resources* and *controllers* to facilitate internal operations of the
-operating system. Talos resources and controllers are very similar to Kubernetes resources and controllers,
-but there are some differences. The content of this document is not required to operate Talos, but it is
-useful for troubleshooting.
+Talos implements concepts of *resources* and *controllers* to facilitate internal operations of the operating system.
+Talos resources and controllers are very similar to Kubernetes resources and controllers, but there are some differences.
+The content of this document is not required to operate Talos, but it is useful for troubleshooting.
 
-Starting with Talos 0.9, most of the Kubernetes control plane boostrapping and operations is implemented
-via controllers and resources which allows Talos to be reactive to configuration changes, environment
-changes (e.g. time sync).
+Starting with Talos 0.9, most of the Kubernetes control plane boostrapping and operations is implemented via controllers and resources which allows Talos to be reactive to configuration changes, environment changes (e.g. time sync).
 
 ## Resources
 
-A resource captures a piece of system state. Each resource belongs to a "Type" which defines resource contents.
+A resource captures a piece of system state.
+Each resource belongs to a "Type" which defines resource contents.
 Resource state can be split in two parts:
 
 * metadata: fixed set of fields describing resource - namespace, type, ID, etc.
 * spec: contents of the resource (depends on resource type).
 
-Resource is uniquely identified by (`namespace`, `type`, `id`). Namespaces provide a way to avoid conflicts on
-duplicate resource IDs.
+Resource is uniquely identified by (`namespace`, `type`, `id`).
+Namespaces provide a way to avoid conflicts on duplicate resource IDs.
 
-At the moment of this writing, all resources are local to the node and stored in memory. So on every reboot
-resource state is rebuilt from scratch (the only exception is `MachineConfig` resource which reflects current
-machine config).
+At the moment of this writing, all resources are local to the node and stored in memory.
+So on every reboot resource state is rebuilt from scratch (the only exception is `MachineConfig` resource which reflects current machine config).
 
 ## Controllers
 
-Controllers run as independent lightweight threads in Talos. The goal of the controller is to reconcile
-the state based on inputs and eventually update outputs.
+Controllers run as independent lightweight threads in Talos.
+The goal of the controller is to reconcile the state based on inputs and eventually update outputs.
 
-A controller can have any number of resource types (and namespaces) as inputs. In other words, it watches
-specified resources for changes and reconciles when these changes occur. A controller might also have additional
-inputs: running reconcile on schedule, watching `etcd` keys, etc.
+A controller can have any number of resource types (and namespaces) as inputs.
+In other words, it watches specified resources for changes and reconciles when these changes occur.
+A controller might also have additional inputs: running reconcile on schedule, watching `etcd` keys, etc.
 
-A controller has a single output: a set of resources of fixed type in a fixed namespace. Only one controller
-can manage resource type in the namespace, so conflicts are avoided.
+A controller has a single output: a set of resources of fixed type in a fixed namespace.
+Only one controller can manage resource type in the namespace, so conflicts are avoided.
 
 ## Querying Resources
 
@@ -118,16 +115,15 @@ NODE         NAMESPACE   TYPE        ID             VERSION
 Command `talosctl get` supports following output modes:
 
 * `table` (default) prints resource list as a table
-* `yaml` prints pretty formatted resources with details, including full metadata spec. This format carries most
-  details from the backend resource (e.g. comments in `MachineConfig` resource)
+* `yaml` prints pretty formatted resources with details, including full metadata spec.
+  This format carries most details from the backend resource (e.g. comments in `MachineConfig` resource)
 * `json` prints same information as `yaml`, some additional details (e.g. comments) might be lost.
   This format is useful for automated processing with tools like `jq`.
 
 ### Watching Changes
 
-If flag `--watch` is appended to the `talosctl get` command, the command switches to watch mode. If list of resources
-was requested, `talosctl` prints initial contents of the list and then appends resource information
-for every change:
+If flag `--watch` is appended to the `talosctl get` command, the command switches to watch mode.
+If list of resources was requested, `talosctl` prints initial contents of the list and then appends resource information for every change:
 
 ```bash
 $ talosctl get svc -w

website/content/docs/v0.11/Learn More/faqs.md

@@ -16,13 +16,16 @@ It's a big change from how operating systems have been managed in the past, but
 
 ## Why no shell or SSH?
 
-Since Talos is fully API-driven, all maintenance and debugging operations should be possible via the OS API. We would like for Talos users to start thinking about what a "machine" is in the context of a Kubernetes cluster.
+Since Talos is fully API-driven, all maintenance and debugging operations should be possible via the OS API.
+We would like for Talos users to start thinking about what a "machine" is in the context of a Kubernetes cluster.
 That is, that a Kubernetes _cluster_ can be thought of as one massive machine, and the _nodes_ are merely additional, undifferentiated resources.
 We don't want humans to focus on the _nodes_, but rather on the _machine_ that is the Kubernetes cluster.
-Should an issue arise at the node level, `talosctl` should provide the necessary tooling to assist in the identification, debugging, and remedation of the issue. However, the API is based on the Principle of Least Privilege, and exposes only a limited set of methods.
+Should an issue arise at the node level, `talosctl` should provide the necessary tooling to assist in the identification, debugging, and remedation of the issue.
+However, the API is based on the Principle of Least Privilege, and exposes only a limited set of methods.
 We envision Talos being a great place for the application of [control theory](https://en.wikipedia.org/wiki/Control_theory) in order to provide a self-healing platform.
 
 ## Why the name "Talos"?
 
 Talos was an automaton created by the Greek God of the forge to protect the island of Crete.
-He would patrol the coast and enforce laws throughout the land. We felt it was a fitting name for a security focused operating system designed to run Kubernetes.
+He would patrol the coast and enforce laws throughout the land.
+We felt it was a fitting name for a security focused operating system designed to run Kubernetes.