Format markdown

Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)`

docs/developers/README.md

@@ -12,8 +12,8 @@ on path `/pvc` by PipelineRun.
   adds a step to copy each output resource to the directory path
   `/pvc/task_name/resource_name`.
 
-- If an input resource includes `from` condition then the `TaskRun`
-  controller adds a step to copy from PVC to directory path
+- If an input resource includes `from` condition then the `TaskRun` controller
+  adds a step to copy from PVC to directory path
   `/pvc/previous_task/resource_name`.
 
 ### How are inputs handled?

docs/tutorial.md

@@ -331,9 +331,9 @@ resource definition.
 # Pipeline
 
 A [`Pipeline`](concepts.md#pipelines) defines a list of tasks to execute in
-order, while also indicating if any outputs should be used as inputs
-of a following task by using [the `from` field](using.md#from).
-The same templating you used in tasks is also available in pipeline.
+order, while also indicating if any outputs should be used as inputs of a
+following task by using [the `from` field](using.md#from). The same templating
+you used in tasks is also available in pipeline.
 
 For example:
 
@@ -369,12 +369,12 @@ spec:
         name: demo-deploy-kubectl
       resources:
         inputs:
-        - name: workspace
-          resource: source-repo
-        - name: image
-          resource: web-image
-          from:
-          - build-skaffold-web
+          - name: workspace
+            resource: source-repo
+          - name: image
+            resource: web-image
+            from:
+              - build-skaffold-web
       params:
         - name: path
           value: /workspace/examples/microservices/leeroy-web/kubernetes/deployment.yaml

docs/using.md

@@ -16,8 +16,8 @@
    specific to your project (e.g. running your particular set of unit tests).
 2. Create a `Pipeline` which expresses the Tasks you would like to run and what
    [PipelineResources](#resources-in-a-pipeline) the Tasks need. Use
-   [`from`](#from) to express when the input of a `Task` should come
-   from the output of a previous `Task`.
+   [`from`](#from) to express when the input of a `Task` should come from the
+   output of a previous `Task`.
 
 See [the example Pipeline](../examples/pipeline.yaml).
 
@@ -66,13 +66,12 @@ spec:
 Sometimes you will have `Tasks` that need to take as input the output of a
 previous `Task`, for example, an image built by a previous `Task`.
 
-Express this dependency by adding `from` on `Resources` that your `Tasks`
-need.
+Express this dependency by adding `from` on `Resources` that your `Tasks` need.
 
 - The (optional) `from` key on an `input source` defines a set of previous
   `PipelineTasks` (i.e. the named instance of a `Task`) in the `Pipeline`
-- When the `from` key is specified on an input source, the version of
-  the resource that is from the defined list of tasks is used
+- When the `from` key is specified on an input source, the version of the
+  resource that is from the defined list of tasks is used
 - `from` can support fan in and fan out
 - The name of the `PipelineResource` must correspond to a `PipelineResource`
   from the `Task` that the referenced `PipelineTask` gives as an output
@@ -98,8 +97,8 @@ For example see this `Pipeline` spec:
 ```
 
 The resource `my-image` is expected to be given to the `deploy-app` `Task` from
-the `build-app` `Task`. This means that the `PipelineResource` `my-image` must also
-be declared as an output of `build-app`.
+the `build-app` `Task`. This means that the `PipelineResource` `my-image` must
+also be declared as an output of `build-app`.
 
 For implementation details, see [the developer docs](docs/developers/README.md).
 
@@ -184,9 +183,9 @@ configure that by edit the `image`'s value in a configmap named
 ### Resource sharing between tasks
 
 Pipeline `Tasks` are allowed to pass resources from previous `Tasks` via the
-[`from`](#from) field. This feature is implemented using
-Persistent Volume Claims under the hood but however has an implication
-that tasks cannot have any volume mounted under path `/pvc`.
+[`from`](#from) field. This feature is implemented using Persistent Volume
+Claims under the hood but however has an implication that tasks cannot have any
+volume mounted under path `/pvc`.
 
 ### Outputs
 

examples/README.md

@@ -72,8 +72,8 @@ demonstrates how the outputs of a `Task` can be given as inputs to the next
 1. Running a `Task` that writes to a `PipelineResource`
 2. Running a `Task` that reads the written value from the `PipelineResource`
 
-The [`Output`](../docs/Concepts.md#outputs) of the first `Task` is given as
-an [`Input`](../docs/Concepts.md#inputs) to the next `Task` thanks to the
+The [`Output`](../docs/Concepts.md#outputs) of the first `Task` is given as an
+[`Input`](../docs/Concepts.md#inputs) to the next `Task` thanks to the
 [`from`](../docs/using.md#from) clause.
 
 #### Output Tasks