📚 Sync docs from alaudadevops/tektoncd-operator on 768c48e46d8d440fe17a0a7ceb774867c4ef5a18

Source: docs: add release notes for v4.2.0 (#349)
Author: l-qing
Ref: refs/heads/release-4.2
Commit: 768c48e46d8d440fe17a0a7ceb774867c4ef5a18

This commit automatically syncs documentation changes from the source-docs repository.

🔗 View source commit: AlaudaDevops/tektoncd-operator@768c48e
🤖 Synced on 2025-08-14 08:08:15 UTC

Author: l-qing

.github/SYNC_INFO.md

@@ -1,10 +1,10 @@
 # Documentation Sync Information
 
-- **Last synced**: 2025-08-11 09:24:02 UTC
+- **Last synced**: 2025-08-14 08:08:15 UTC
 - **Source repository**: alaudadevops/tektoncd-operator
-- **Source commit**: [9e1a9dc8a45ad0123347d5d61cf8a8b8890a49e3](https://github.com/alaudadevops/tektoncd-operator/commit/9e1a9dc8a45ad0123347d5d61cf8a8b8890a49e3)
-- **Triggered by**: tik-seven
-- **Workflow run**: [#33](https://github.com/alaudadevops/tektoncd-operator/actions/runs/16876030255)
+- **Source commit**: [768c48e46d8d440fe17a0a7ceb774867c4ef5a18](https://github.com/alaudadevops/tektoncd-operator/commit/768c48e46d8d440fe17a0a7ceb774867c4ef5a18)
+- **Triggered by**: l-qing
+- **Workflow run**: [#39](https://github.com/alaudadevops/tektoncd-operator/actions/runs/16959574301)
 
 ## Files synced:
 - docs/

docs/en/apis/advanced_apis/results/intro.md

@@ -448,7 +448,7 @@ CEL expressions typically correspond one-to-one with JSON/protobuf fields. In Te
 
 #### Using Operators
 
-Now that we can access fields, you can create filters using operators. Here’s a list of operators that can be used in CEL expressions:
+Now that we can access fields, you can create filters using operators. Here's a list of operators that can be used in CEL expressions:
 
 | Operator                | Description                | Example                                      |
 | ----------------------- | -------------------------- | -------------------------------------------- |
@@ -463,7 +463,7 @@ Now that we can access fields, you can create filters using operators. Here’s
 
 #### Using Functions
 
-Many functions can be used in CEL expressions. Here’s a list of functions that can be used in CEL expressions. The strings in function parameters represent the expected type of the arguments:
+Many functions can be used in CEL expressions. Here's a list of functions that can be used in CEL expressions. The strings in function parameters represent the expected type of the arguments:
 
 | Function                                             | Description                 | Example                                      |
 | ----------------------------------------------------| ----------------------------| -------------------------------------------- |
@@ -482,7 +482,7 @@ You can also nest function calls and mix operators to create complex filtering e
 
 ### Using CEL Filtering Expressions with gRPC
 
-You can pass a filter to gRPC requests by specifying `filter=<cel-expression>`. Be sure to use the correct quoting in your queries or escape if necessary. Here’s an example:
+You can pass a filter to gRPC requests by specifying `filter=<cel-expression>`. Be sure to use the correct quoting in your queries or escape if necessary. Here's an example:
 
 ```bash
 grpc_cli call --channel_creds_type=ssl \
@@ -494,7 +494,7 @@ grpc_cli call --channel_creds_type=ssl \
 
 ### Using CEL Filtering Expressions with REST
 
-You can pass a filter to REST requests by specifying `filter=<cel-expression>` in your query. Here’s an example:
+You can pass a filter to REST requests by specifying `filter=<cel-expression>` in your query. Here's an example:
 
 ```bash
 curl --insecure \
@@ -505,7 +505,7 @@ curl --insecure \
 
 ### Using CEL Filtering Expressions with `tkn-results`
 
-If you have installed `tkn-results` CLI independently or as a plugin to `tkn`, you can filter Results using the `--filter=<cel-expression>` flag. Here’s an example:
+If you have installed `tkn-results` CLI independently or as a plugin to `tkn`, you can filter Results using the `--filter=<cel-expression>` flag. Here's an example:
 
 ```bash
 tkn results records list default/results/- --filter="data.metadata.annotations.contains('bar')"
@@ -544,6 +544,8 @@ To request a list of objects in a specific order, include the `order_by` query p
 
 Fields supported in `order_by`:
 
+<!-- lint ignore table-size -->
+
 | Field Name       |
 | ---------------- |
 | `create_time`   |

docs/en/chains/concepts/understanding_tekton_chains.mdx

@@ -178,6 +178,8 @@ There are several ways to specify input and output artifacts:
 - Used to track source code repository details
 - Helps in provenance generation for source code
 
+{/* lint ignore code-block-split-list */}
+
 ```yaml
 results:
   - name: CHAINS-GIT_URL
@@ -186,7 +188,7 @@ results:
     type: string
 ```
 
-:::details{title="Example TaskRun"}
+:::details \{title="Example TaskRun"}
 ```yaml
 apiVersion: tekton.dev/v1
 kind: TaskRun
@@ -228,6 +230,8 @@ spec:
 - Used to specify input artifacts that influenced the build process
 - Helps track dependencies and source materials
 
+{/* lint ignore code-block-split-list */}
+
 ```yaml
 results:
   - name: first-ARTIFACT_INPUTS
@@ -237,7 +241,7 @@ results:
       digest: {}
 ```
 
-:::details{title="Example TaskRun"}
+:::details \{title="Example TaskRun"}
 ```yaml
 apiVersion: tekton.dev/v1
 kind: TaskRun
@@ -280,7 +284,7 @@ results:
     type: string
 ```
 
-:::details{title="Example TaskRun"}
+:::details \{title="Example TaskRun"}
 ```yaml
 apiVersion: tekton.dev/v1
 kind: TaskRun
@@ -310,13 +314,15 @@ spec:
 - Can specify multiple images, separated by commas or newlines
 - Each image must include the complete digest
 
+{/* lint ignore code-block-split-list */}
+
 ```yaml
 results:
   - name: IMAGES
     type: string
 ```
 
-:::details{title="Example TaskRun"}
+:::details \{title="Example TaskRun"}
 ```yaml
 apiVersion: tekton.dev/v1
 kind: TaskRun
@@ -342,6 +348,8 @@ spec:
 - Similar to IMAGE_URL/IMAGE_DIGEST but with different naming convention
 - Used for specifying artifact location and its digest
 
+{/* lint ignore code-block-split-list */}
+
 ```yaml
 results:
   - name: first-ARTIFACT_URI
@@ -355,6 +363,8 @@ results:
 - Uses object type results
 - Must include uri and digest fields
 
+{/* lint ignore code-block-split-list */}
+
 ```yaml
 results:
   - name: first-ARTIFACT_OUTPUTS
@@ -364,7 +374,7 @@ results:
       digest: {}
 ```
 
-:::details{title="Example TaskRun"}
+:::details \{title="Example TaskRun"}
 ```yaml
 apiVersion: tekton.dev/v1
 kind: TaskRun

docs/en/chains/how_to/image_signature_verification.mdx

@@ -138,7 +138,8 @@ spec:
                       ignoreTlog: true
 ```
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
+{/* lint ignore no-deep-list */}
 - `spec.rules[].match.any[].resources`: The resources to be matched and validated.
   - `kinds`: The kinds of the resources to be matched and validated.
     - `Pod`: The Pod resources.

docs/en/chains/how_to/sbom_verification.mdx

@@ -213,7 +213,7 @@ In production environments, you would typically:
 3. This approach ensures proper version control and maintains the separation between code and pipeline configuration
 :::
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The same as in [Step 4: Create a Sample Pipeline](../quick_start/signed_provenance.mdx#step-4-create-a-sample-pipeline), but adds the following content:
   - `workspaces`:
     - `signkey`: The workspace for private keys and passwords used for image signatures.
@@ -261,7 +261,7 @@ spec:
           storageClassName: <nfs>
 ```
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The same as in [Step 5: Run a Sample Pipeline](../quick_start/signed_provenance.mdx#step-5-run-a-sample-pipeline). Below only introduces the differences.
 - `workspaces`
   - `signkey`: the secret name of the signing key.
@@ -342,7 +342,7 @@ $ cosign verify-attestation --key cosign.pub --type cyclonedx $IMAGE | jq -r '.p
 
 The output will be similar to the following, which contains the components information of the image.
 
-:::details{title="cyclonedx SBOM attestation"}
+:::details \{title="cyclonedx SBOM attestation"}
 ```json
 {
   "_type": "https://in-toto.io/Statement/v0.1",
@@ -384,7 +384,8 @@ The output will be similar to the following, which contains the components infor
 ```
 :::
 
-:::details{title="Description of the fields"}
+:::details \{title="Description of the fields"}
+{/* lint ignore no-deep-list */}
 - `predicateType`: The type of the predicate.
 - `predicate`:
   - `components`: The components of the image.
@@ -485,7 +486,7 @@ spec:
                        PkgIDs: {{ scanner.result.Results[].Vulnerabilities[?CVSS.redhat.V3Score > `1.0`].PkgID[] }}.
 ```
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The policy is largely consistent with the one in [Image Signature Verification](../how_to/image_signature_verification.mdx#step-81-create-a-kyverno-policy-to-allow-only-signed-images-to-be-deployed)
 - `spec.rules[0].verifyImages[].attestations[0].conditions`
   - `type`: The cyclonedx SBOM attestation type is `https://cyclonedx.org/bom`

docs/en/chains/how_to/vulnerability_scanning_verification.mdx

@@ -247,7 +247,7 @@ In production environments, you would typically:
 3. This approach ensures proper version control and maintains the separation between code and pipeline configuration
 :::
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The same as in [Step 4: Create a Sample Pipeline](../quick_start/signed_provenance.mdx#step-4-create-a-sample-pipeline), but adds the following content:
   - `workspaces`:
     - `signkey`: The workspace for private keys and passwords used for image signatures.
@@ -299,7 +299,7 @@ spec:
           storageClassName: <nfs>
 ```
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The same as in [Step 5: Run a Sample Pipeline](../quick_start/signed_provenance.mdx#step-5-run-a-sample-pipeline). Below only introduces the differences.
 - `workspaces`
   - `signkey`: the secret name of the signing key.
@@ -379,7 +379,7 @@ $ cosign verify-attestation --key cosign.pub --type vuln $IMAGE | jq -r '.payloa
 ```
 The output will be similar to the following, which contains the vulnerability scan results.
 
-:::details{title="cosign vuln attestation"}
+:::details \{title="cosign vuln attestation"}
 ```json
 {
   "_type": "https://in-toto.io/Statement/v0.1",
@@ -479,7 +479,8 @@ The output will be similar to the following, which contains the vulnerability sc
 ```
 :::
 
-:::details{title="Description of the fields"}
+:::details \{title="Description of the fields"}
+{/* lint ignore no-deep-list */}
 - `predicateType`: The type of the predicate.
 - `predicate.scanner`:
   - `uri`: The URI of the scanner.
@@ -589,7 +590,7 @@ spec:
                         PkgIDs: {{ scanner.result.Results[].Vulnerabilities[?CVSS.redhat.V3Score > `1.0`].PkgID[] }}.
 ```
 
-:::details{title="Explanation of YAML fields"}
+:::details \{title="Explanation of YAML fields"}
 - The policy is largely consistent with the one in [Image Signature Verification](../how_to/image_signature_verification.mdx#step-81-create-a-kyverno-policy-to-allow-only-signed-images-to-be-deployed)
 - `spec.rules[0].verifyImages[].attestations[0].conditions`
   - `type`: The cosign vuln attestation type is `https://cosign.sigstore.dev/attestation/vuln/v1`

docs/en/configure/customize_options.mdx

@@ -230,6 +230,8 @@ Using the `pipeline` component as an example, this section describes how to conf
   - Change the number of replicas for `Deployment` `tekton-events-controller` to 2
   - Modify the `resources` configuration of `Deployment` `tekton-events-controller`
 
+  {/* lint ignore code-block-split-list */}
+
   ```yaml
   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig

docs/en/development/update-component/index.md

@@ -82,21 +82,21 @@ To use releases from your own branch or specific commit:
 
 1. **Edit components.yaml**: Update the `revision` field for the component you want to update:
 
-```yaml
-tektoncd-hub:
-  revision: your-feature-branch  # or specific commit hash
-  releases:
-    - remote_path: api
-      local_path: tekton-hub/api
-    - remote_path: hub-info
-      local_path: tekton-hub/hub-info
-```
+    ```yaml
+    tektoncd-hub:
+      revision: your-feature-branch  # or specific commit hash
+      releases:
+        - remote_path: api
+          local_path: tekton-hub/api
+        - remote_path: hub-info
+          local_path: tekton-hub/hub-info
+    ```
 
 2. **Run the update process**:
 
-```bash
-make update-components
-```
+    ```bash
+    make update-components
+    ```
 
 ### 2.3 Update Process Details
 
@@ -115,22 +115,22 @@ To add a new component to the automated update process:
 
 1. **Add component configuration** to `components.yaml`:
 
-```yaml
-your-new-component:
-  revision: main  # or your target branch
-  releases:
-    - remote_path: main
-      local_path: your-component/main
-    - remote_path: sidecar
-      local_path: your-component/sidecar
-      local_name: sidecar.yaml
-```
+    ```yaml
+    your-new-component:
+      revision: main  # or your target branch
+      releases:
+        - remote_path: main
+          local_path: your-component/main
+        - remote_path: sidecar
+          local_path: your-component/sidecar
+          local_name: sidecar.yaml
+    ```
 
 2. **Run the update process**:
 
-```bash
-make update-components
-```
+    ```bash
+    make update-components
+    ```
 
 ### 3.2 Component Structure Requirements