fix pipeline doc

Signed-off-by: LiZhenCheng9527 <[email protected]>

docs/content/en/docs/pipeline/operation.md

@@ -11,14 +11,13 @@ This guide provides manual for Kurator pipelines, detailing steps for applying p
 
 ## Applying Pipeline Examples
 
-This section demonstrate the practical operation of Kurator pipelines, 
-highlighting two key examples: one with a predefined task and another with a custom task. 
+This section demonstrate the practical operation of Kurator pipelines.
+Highlighting two key examples: one with a predefined task and another with a custom task.
 These examples provide insights into the functionality and adaptability of Kurator pipelines in different scenarios.
 
-
 ### Creating a Namespace
 
-The first step involves creating a dedicated namespace in Kubernetes. 
+The first step involves creating a dedicated namespace in Kubernetes.
 
 ```console
 kubectl create ns kurator-pipeline
@@ -101,12 +100,10 @@ el-test-predefined-task-listener-7d5774d7c-82whm   1/1     Running   0
 
 ## Exposing Services and Webhook Settings
 
-Within the Kubernetes cluster, both `el-test-custom-task-listener` and `el-test-predefined-task-listener` are configured as ClusterIP services, 
-meaning they are only accessible internally. 
-To enable external systems, like webhooks, to access these services, we need to expose them outside the cluster. 
+Within the Kubernetes cluster, both `el-test-custom-task-listener` and `el-test-predefined-task-listener` are configured as ClusterIP services, meaning they are only accessible internally.
+To enable external systems, like webhooks, to access these services, we need to expose them outside the cluster.
 
-For demonstration and testing convenience, a straightforward method for this is by using the `kubectl port-forward` command, 
-which allows us to forward a port from an internal service to a local server or computer.
+For demonstration and testing convenience, a straightforward method for this is by using the `kubectl port-forward` command, which allows us to forward a port from an internal service to a local server or computer.
 
 ### Exposing Services
 
@@ -126,14 +123,14 @@ kubectl port-forward --address 0.0.0.0 service/el-test-predefined-task-listener
 
 ### Setting up Webhooks for Pipeline
 
-The pipeline events here are triggered via GitHub webhooks. 
-This means that once the webhooks are configured to trigger on certain events, 
+The pipeline events here are triggered via GitHub webhooks.
+This means that once the webhooks are configured to trigger on certain events,
 like code merges, the tasks described in the pipeline will automatically execute in sequence.
 
-To set up webhooks for the pipeline, select the GitHub repository you want to associate with the pipeline. 
-For guidance on creating the webhook, 
-refer to the official GitHub documentation at [Creating Webhooks](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks). 
-In our example, the `Payload URL` should be set to your cluster's external address plus port numbers 30000 and 30001, 
+To set up webhooks for the pipeline, select the GitHub repository you want to associate with the pipeline.
+For guidance on creating the webhook,
+refer to the official GitHub documentation at [Creating Webhooks](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks).
+In our example, the `Payload URL` should be set to your cluster's external address plus port numbers 30000 and 30001,
 and the trigger event selected as "Just the push event."
 
 Once the webhook is set up, you will see the status in GitHub page like the following indicating that the webhook is properly configured.
@@ -145,7 +142,6 @@ link="./image/webhook.png"
 > After setting up webhooks, it's need to note that users may initially see a red exclamation mark instead of a green check mark.
 Once a webhook is successfully triggered for the first time, the icon will change to a green check mark, indicating that everything is functioning correctly.
 
-
 ## Triggering the Pipeline
 
 ### Trigger the Github Event

docs/content/en/docs/pipeline/setting.md

@@ -23,10 +23,12 @@ kubectl apply --filename https://storage.googleapis.com/tekton-releases/chains/l
 
 ### Configuring Authentication for Private Repositories
 
-Since the first task in a pipeline often involves pulling code from a Git repository, it's essential to configure Git repository authentication. 
+Since the first task in a pipeline often involves pulling code from a Git repository, it's essential to configure Git repository authentication.
 This can be done by creating a Kubernetes secret containing the authentication details. Use the following command to create this secret:
 
 ```console
+kubeclt create ns kurator-pipeline
+
 kubectl create secret generic git-credentials \
   --namespace=kurator-pipeline \
   --from-literal=.gitconfig=$'[credential "https://github.com"]\n\thelper = store' \
@@ -35,7 +37,7 @@ kubectl create secret generic git-credentials \
 
 ## Pipeline Field Introduction
 
-Understanding the core fields of a Pipeline in Kurator is crucial for effective configuration and utilization. 
+Understanding the core fields of a Pipeline in Kurator is crucial for effective configuration and utilization.
 A Pipeline in Kurator contains a collection of tasks, defining the workflow of a CI/CD process.
 
 Here is an example of a typical pipeline:
@@ -64,11 +66,11 @@ spec:
           - "cat $(workspaces.source.path)/README.md"
 ```
 
-In the Pipeline, tasks are executed in the sequence they are listed. 
-Each task encompasses detailed information regarding the specific steps that need to be undertaken. 
+In the Pipeline, tasks are executed in the sequence they are listed.
+Each task encompasses detailed information regarding the specific steps that need to be undertaken.
 
 The tasks are structured as an array, comprising either predefinedTasks or CustomTasks.
-**PredefinedTask** provides users the option to select from a set of predefined tasks and input their parameters. 
+**PredefinedTask** provides users the option to select from a set of predefined tasks and input their parameters.
 Conversely, **CustomTask** offers the flexibility to directly define a task, particularly when the desired task is not available in the list of predefined tasks.
 
 ## Predefined Tasks
@@ -85,7 +87,7 @@ They streamline the initial setup process and provide a quick start for users.
 | `go-lint`      | Performs linting on Go source code, using golangci-lint. | Ensures coding style and common error checks. | - `package`, `context`, `flags`, `version`, `GOOS`, `GOARCH`, `GO111MODULE`, `GOCACHE`, `GOMODCACHE`, `GOLANGCI_LINT_CACHE` |
 | `build-and-push-image` | Builds and pushes a Docker image using Kaniko. | Enables building and storing Docker images. | - `IMAGE`, `DOCKERFILE`, `CONTEXT`, `EXTRA_ARGS`, `BUILDER_IMAGE` |
 
-### Example of a Predefined Tasks 
+### Example of a Predefined Tasks
 
 To configure a predefined Task, simply reference the task template in your pipeline definition, and provide any required parameters based on your specific requirements. 
 For example:
@@ -123,15 +125,12 @@ A Custom Task allows for greater flexibility by defining tasks directly within t
 
 ```yaml
 tasks:
-  - name: custom-task-example
+  - name: cat-readme
     customTask:
-      image: 'example-image'
+      image: zshusers/zsh:4.3.15
       command:
-        - '/bin/sh'
-        - '-c'
+        - /bin/sh
+        - -c
       args:
-        - 'echo Hello World'
-      env:
-        - name: EXAMPLE_ENV
-          value: 'example'
+        - "cat $(workspaces.source.path)/README.md"' | kubectl apply -f -
 ```