fix lint issues

.gitignore

@@ -1 +1,2 @@
-docs/lab1/5_create-service-account copy.md
+docs/lab1/5_create-service-account copy.md
+docs/tmp1.md

docs/README.md

@@ -72,7 +72,7 @@ The resources are used as follows.
 
 A Task executes a Pod and is a sequence of Steps. A Step is equivalent to a Container. You can define the name, image, environment and a script to run inside the container.  All Steps in a Task can access a shared workspace, an implicit volume of the pod.
 
-A Pipeline is a collection of Tasks that can run sequentially or conditionally. Pipeline has access to a shared persistent volume (workspace) and combines tasks through the workspace and results to certain output. The pipeline also provides a finalizer function. 
+A Pipeline is a collection of Tasks that can run sequentially or conditionally. Pipeline has access to a shared persistent volume (workspace) and combines tasks through the workspace and results to certain output. The pipeline also provides a finalizer function.
 
 Pipeline and Tasks are executed by PipelineRun and TaskRun. To automatically invoke these you can create a Trigger. A TriggerBinding extracts data from the event payload, and a TriggerTemplate creates the template for the PipelineRun. The EventListener is a Custom Resource Definition (CRD) that combines the TriggerBinding and the TriggerTemplate. You can find existing pipeline resources in the Tekton Catalog or Tekton Hub.
 

docs/lab1/4_create-pipeline.md

@@ -73,7 +73,7 @@ default inside the task (if it's an optional parameter).
 
 For example, our pipeline `build-and-deploy-pipeline` defines a parameter `pathToContext` that defaults to `src`. If you run the pipeline you can pass a value for this parameter and override the default. In the `build-and-push-image` task of the pipeline, a `CONTEXT` parameter is defined, which corresponds to the `CONTEXT` parameter that is defined in the `kaniko` task. The value of this parameter in the kaniko task will be set to the value that our pipeline parameter `pathToContext` is set to.
 
-However, the parameter `DOCKERFILE` that is defined in our `kaniko` task and there defaults to `./Dockerfile `, is not exposed in the pipeline under the `build-and-push-image` task that references the `kaniko` task. So the pipeline is not overriding the value of the `DOCKERFILE` parameter, and thus it defaults to the value `./Dockerfile`.
+However, the parameter `DOCKERFILE` that is defined in our `kaniko` task and there defaults to `./Dockerfile`, is not exposed in the pipeline under the `build-and-push-image` task that references the `kaniko` task. So the pipeline is not overriding the value of the `DOCKERFILE` parameter, and thus it defaults to the value `./Dockerfile`.
 
 Our `build-and-deploy-pipeline` pipeline also shows how to take the result of one task and pass it to another task. You saw earlier that the `kaniko` task defines a result named `IMAGE-DIGEST` that holds the digest of the built image.
 

docs/tmp1.md

@@ -68,4 +68,4 @@ Taskruns
  picalc-pr-c7hsb-deploy-to-cluster-mwvfs   deploy-to-cluster   9 minutes ago    10 seconds   Succeeded
  picalc-pr-c7hsb-build-and-push-image-s8rrg     build-and-push-image     10 minutes ago   1 minute     Succeeded
  picalc-pr-c7hsb-clone-repo-pvbsk          clone-repo          12 minutes ago   1 minute     Succeeded
-``` -->
+``` -->