Update working-with-pipelines.md

publish/working-with-pipelines/working-with-pipelines.md

@@ -42,7 +42,7 @@ guide-category: pipelines
 - sign the image
 - retag an image
 - deploy the application to the Kubernetes cluster
-- promote a service to a GitOps repo (This feature is Tech Preview in this release)
+- promote a service to a GitOps repository (This feature is Tech Preview in this release)
 - deploy a complete microservice scenario using Kustomize (This feature is Tech Preview in this release)
 
 You can also create your own tasks and pipelines and customize the pre-built pipelines and tasks. All tasks and pipelines are activated by the product operator.
@@ -71,7 +71,7 @@ The pipeline invokes the following tasks to accomplish the steps listed:
   * [build-push-promote-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/build-push-promote-task.yaml)
     This task first does a pre-build governance policy check to validate the stack version in the application repository is allowed to build based on the governance policy that is configured. It then builds a container image from the artifacts in the git-source repository by using `appsody build`. The appsody build command leverages [Buildah](https://github.com/containers/buildah) to build the image. The command also generates the `app-deploy.yaml` that is used for deployment. If there is already a copy of the `app-deploy.yaml` file in the source repository, it is merged with the new one generated by this step. After the image is built, the image is then optionally signed if the necessary configuration is setup. Refer to the [image signing operator](https://github.com/kabanero-io/kabanero-security/tree/master/pipelines/samples/signing-operator) for more information on configuring image signing. The image is then pushed to the configured image registry.
 
-    (Tech preview feature) A configmap called `gitops-map` in the Kabanero namespace can optionally be configured to promote the service to a GitOps repo after the build.  The step will invoke the [`services promote`](https://github.com/rhd-gitops-example/services) command to create a PR with the updated `app-deploy.yaml` file in the configured GitOps repo. The following key value pairs should be setup in the configmap:
+    (Tech preview feature) A configmap called `gitops-map` in the Kabanero namespace can optionally be configured to promote the service to a GitOps repository after the build.  The step will invoke the [`services promote`](https://github.com/rhd-gitops-example/services) command to create a PR with the updated `app-deploy.yaml` file in the configured GitOps repository. The following key value pairs should be setup in the configmap:
     ```
     kind: ConfigMap 
     apiVersion: v1 
@@ -110,7 +110,7 @@ The pipeline invokes the following tasks to accomplish the steps listed:
 
 This event triggers the [image-retag-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-pl.yaml) pipeline, which leverages the [image-retag-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/image-retag-task.yaml) to create a new tag of the image to match with the git release.
 
-* **The pull request in the GitOps repo is merged** (This feature is Tech Preview in this release)
+* **The pull request in the GitOps repository is merged** (This feature is Tech Preview in this release)
 When the PR that was created by the promote step of the `build-push-promote-pl` is merged in the GitOps repository, it triggers the [deploy-kustomize-pl.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-pl.yaml) pipeline, which leverages the [deploy-kustomize-task.yaml](https://github.com/kabanero-io/kabanero-pipelines/blob/master/pipelines/incubator/events/deploy-kustomize-task.yaml) to trigger a deployment to the environment configured in the GitOps repository.
 
 ### Incubator pipelines
@@ -137,7 +137,7 @@ This is the primary pipeline that showcases a majority of the tasks supplied in
 
    The `image-scan-task` task initiates a container scan of the image published by the `build-push-task` using OpenSCAP. The results of the scan are published in the logs of the task.
   
-For more tasks and pipelines, see [the kabanero-pipelines repo](https://github.com/kabanero-io/kabanero-pipelines).
+For more tasks and pipelines, see [the kabanero-pipelines repository](https://github.com/kabanero-io/kabanero-pipelines).
 
 ### Experimental GitOps pipelines (Tech Preview)
 
@@ -240,9 +240,9 @@ When the product operator activates the CRD, it associates the pipelines in the
 
 ## Creating and updating your own tasks and pipelines
 
-The default tasks and pipelines can be updated by forking the Kabanero Pipelines repo and editing the files under `pipelines/`. An easy way to generate the archive for use by the Kabanero CRD is to run the [package.sh](https://github.com/kabanero-io/kabanero-pipelines/blob/master/ci/package.sh) script from the root directory of the pipelines project. The script generates the archive files with the necessary pipeline artifacts and a `manifest.yaml` file that describes the contents of the archive. It generates the pipelines archive file under `ci/assests`. It generates separate archives for the legacy incubator pipelines, events pipelines, and the experimental GitOps pipleines.
+The default tasks and pipelines can be updated by forking the Kabanero Pipelines repository and editing the files under `pipelines/`. An easy way to generate the archive for use by the Kabanero CRD is to run the [package.sh](https://github.com/kabanero-io/kabanero-pipelines/blob/master/ci/package.sh) script from the root directory of the pipelines project. The script generates the archive files with the necessary pipeline artifacts and a `manifest.yaml` file that describes the contents of the archive. It generates the pipelines archive file under `ci/assests`. It generates separate archives for the legacy incubator pipelines, events pipelines, and the experimental GitOps pipleines.
 
-Alternatively, you can run the Travis build against a release of your pipelines repo, which also generates the archive file with a `manifest.yaml` file and attaches it to your release.
+Alternatively, you can run the Travis build against a release of your pipelines repository, which also generates the archive file with a `manifest.yaml` file and attaches it to your release.
 
 For more detailed instructions, see [Curating Pipelines](../curating-pipelines/curating-pipelines.html)
 
@@ -360,9 +360,9 @@ Explore how to use pipelines to build and manage application stacks.
 
 1. [Kabanero foundation](https://github.com/kabanero-io/kabanero-foundation) must be installed on a supported Kubernetes deployment.
 
-1. A persistent volume must be configured. See the following section for details.
+1. A persistent volume must be configured. See the **Getting started** section for details.
 
-1. Secrets for the git repo (if private) and image repository
+1. Secrets for the GitHub repository (if private) and image repository
 
 ## Getting started
 
@@ -400,25 +400,25 @@ If you are developing a new pipeline and want to test it in a tight loop, you ca
    oc login <master node IP>:8443
    ```
 
-1. Clone the pipelines repo
+1. Clone the pipelines repository:
 
    ```shell
    git clone https://github.com/kabanero-io/kabanero-pipelines
    ```
 
-1. Run the following script with the appropriate parameters
+1. Run this script with the appropriate parameters:
 
    ```shell
    cd ./pipelines/sample-helper-files/./manual-pipeline-run-script.sh -r [git_repo of the Appsody project] -i [docker registery path of the image to be created] -c [application stack name of which pipeline to be run]"
    ```
 
-   - The following example is configured to use the dockerhub container registry:
+   - When using the dockerhub container registry:
 
       ```shell
        ./manual-pipeline-run-script.sh -r https://github.com/mygitid/appsody-test-project -i index.docker.io/mydockeid/my-java-openliberty-image -c java-openliberty"
       ```
 
-   - The following example is configured to use the local OpenShift container registry:
+   - When using the local OpenShift container registry:
 
       ```shell
        ./manual-pipeline-run-script.sh -r https://github.com/mygitid/appsody-test-project -i docker-registry.default.svc:5000/kabanero/my-java-openliberty-image -c java-openliberty"
@@ -445,7 +445,7 @@ Follow these steps to run a pipeline directly from the command line:
 
    Use the `pipeline-resource-template.yaml` file to create the `PipelineResources`. The `pipeline-resource-template.yaml` is provided in the pipelines [/pipelines/sample-helper-files](https://github.com/kabanero-io/kabanero-pipelines/tree/master/pipelines/sample-helper-files) directory. Update the docker-image URL. You can use the sample GitHub repository or update it to point to your own GitHub repository.
 
-1. After you update the file, apply it as shown in the following example:
+1. After you update the file, apply it as shown in this example:
 
    ```shell
    oc apply -f <stack-name>-pipeline-resources.yaml
@@ -480,7 +480,7 @@ You can check the status of the pipeline run from the Kubernetes console, comman
 
 ### Checking pipeline run status from the pipelines dashboard
 
-1. Log in to the pipelines dashboard and click `Pipeline runs' in the sidebar menu.
+1. Log in to the pipelines dashboard and click `Pipeline runs` in the sidebar menu.
 
 1. Find your pipeline run in the list and click it to check the status and find logs. You can see logs and status for each step and task.
 
@@ -495,7 +495,7 @@ oc -n kabanero describe pipelinerun.tekton.dev/<pipeline-run-name>
 
 You can also see pods for the pipeline runs, for which you can specify `oc describe` and `oc logs` to get more details.
 
-If the pipeline run was successful, you can see a Docker image in our Docker registry and a pod that’s running your application.
+If the pipeline run was successful, you can see a Docker image in our Docker registry and a pod that is running your application.
 
 
 <!--