📚 Sync docs from alaudadevops/tektoncd-operator on 50e11286975a242b1aa4c39d61aa26321e94da9c

edge-katanomi-app2[bot] · edge-katanomi-app2[bot] · commit 24eee22889ff · 2026-03-30T13:27:40.000Z
Source: chore: upgrade yarn and refresh docs (#1523) Author: l-qing Ref: refs/heads/release-4.2 Commit: 50e11286975a242b1aa4c39d61aa26321e94da9c This commit automatically syncs documentation changes from the source-docs repository. 🔗 View source commit: https://github.com/alaudadevops/tektoncd-operator/commit/50e11286975a242b1aa4c39d61aa26321e94da9c 🤖 Synced on 2026-03-30 13:27:40 UTC
diff --git a/.github/SYNC_INFO.md b/.github/SYNC_INFO.md
@@ -1,10 +1,10 @@
 # Documentation Sync Information
 
-- **Last synced**: 2026-03-11 03:45:46 UTC
+- **Last synced**: 2026-03-30 13:27:40 UTC
 - **Source repository**: alaudadevops/tektoncd-operator
-- **Source commit**: [0658e7f0f0def0affd57c43b8f32dd6ec7a6f016](https://github.com/alaudadevops/tektoncd-operator/commit/0658e7f0f0def0affd57c43b8f32dd6ec7a6f016)
+- **Source commit**: [50e11286975a242b1aa4c39d61aa26321e94da9c](https://github.com/alaudadevops/tektoncd-operator/commit/50e11286975a242b1aa4c39d61aa26321e94da9c)
 - **Triggered by**: edge-katanomi-app2[bot]
-- **Workflow run**: [#160](https://github.com/alaudadevops/tektoncd-operator/actions/runs/22935701493)
+- **Workflow run**: [#169](https://github.com/alaudadevops/tektoncd-operator/actions/runs/23747165167)
 
 ## Files synced:
 - docs/
diff --git a/.yarn/releases/yarn-4.10.3.cjs b/.yarn/releases/yarn-4.10.3.cjs
diff --git a/.yarn/releases/yarn-4.13.0.cjs b/.yarn/releases/yarn-4.13.0.cjs
diff --git a/docs/en/chains/concepts/core_concepts.mdx b/docs/en/chains/concepts/core_concepts.mdx
@@ -46,7 +46,7 @@ Image attestation is used for storing and verifying metadata information related
 - [Vulnerability scan results](#vulnerability-scan-results)
 - [Custom metadata](#custom-metadata-attestation)
 
-### SLSA Provenance
+### SLSA Provenance \{#slsa-provenance}
 
 [SLSA Provenance](https://slsa.dev/provenance/v1) is metadata containing verifiable information about software artifacts, describing how they were built, what sources were used, and who built them. In Tekton Chains, provenance is cryptographically signed to ensure its integrity and authenticity.
 
@@ -55,7 +55,7 @@ There are two types of provenance in Tekton Chains:
 - **Task-level provenance**: Captures details about a specific TaskRun execution
 - **Pipeline-level provenance**: Captures the entire PipelineRun execution, including all child TaskRuns
 
-### SBOM (Software bill of materials)
+### SBOM (Software bill of materials) \{#sbom-software-bill-of-materials}
 
 [SBOM](https://www.ntia.gov/page/software-bill-materials) is a nested inventory for software, a list of ingredients that make up software components, including:
 - Software components
@@ -67,15 +67,15 @@ SBOM can be in various formats, such as:
 - [SPDX](https://spdx.dev/use/specifications/)
 - [CycloneDX](https://cyclonedx.org/specification/overview/)
 
-### Vulnerability scan results
+### Vulnerability scan results \{#vulnerability-scan-results}
 
 [Cosign Vulnerability Scan results](https://github.com/sigstore/cosign/blob/main/specs/COSIGN_VULN_ATTESTATION_SPEC.md) record the security assessment of the software build process, including:
 - Scanner information (name, version)
   - Vulnerability database information
 - List of discovered vulnerabilities and their severity
 - Remediation recommendations
 
-### Custom metadata
+### Custom metadata \{#custom-metadata-attestation}
 
 Custom metadata can be added as needed to support specific security requirements.
 
diff --git a/docs/en/chains/concepts/understanding_tekton_chains.mdx b/docs/en/chains/concepts/understanding_tekton_chains.mdx
@@ -157,7 +157,7 @@ data:
   artifacts.oci.signer: "x509"
 ```
 
-### Type Hinting
+### Type Hinting \{#type-hinting}
 
 :::tip
 More details about type hinting can be found in the [Tekton Chains Type Hinting](https://tekton.dev/docs/chains/slsa-provenance/#type-hinting) documentation.
@@ -443,4 +443,4 @@ artifacts.oci.signer: "x509"
 - [In-toto Attestation](https://github.com/in-toto/attestation)
 - [Sigstore Project](https://www.sigstore.dev/)
 - [SBOM](https://www.ntia.gov/page/software-bill-materials)
-- [Cosign Vulnerability Scan results](https://github.com/sigstore/cosign/blob/main/specs/COSIGN_VULN_ATTESTATION_SPEC.md)
+- [Cosign Vulnerability Scan results](https://github.com/sigstore/cosign/blob/main/specs/COSIGN_VULN_ATTESTATION_SPEC.md)
diff --git a/docs/en/chains/configure/authentication_for_chains.mdx b/docs/en/chains/configure/authentication_for_chains.mdx
@@ -16,7 +16,7 @@ Authentication must be set up to take advantage of the following features in Cha
 * Pushing signatures to an OCI registry after signing an image
 * Using Fulcio to get Signing Certificates when utilizing Keyless signing
 
-## OCI Registry Authentication
+## OCI Registry Authentication \{#oci-registry-authentication}
 
 To push to an OCI registry, the Chains controller will look for credentials in two places:
 
@@ -94,7 +94,7 @@ spec:
     - name: registry-credentials
 ```
 
-#### Using ServiceAccount
+#### Using ServiceAccount \{#using-serviceaccount}
 
 Give the service account access to the secret:
 
diff --git a/docs/en/chains/configure/signing_key_configuration.mdx b/docs/en/chains/configure/signing_key_configuration.mdx
@@ -47,7 +47,7 @@ metadata:
 type: Opaque
 ```
 
-### Get the Signing Public Key
+### Get the Signing Public Key \{#get-the-signing-public-key}
 
 :::tip
 If you don't have permission, you can ask the administrator to get the public key.
@@ -58,7 +58,7 @@ $ export NAMESPACE=<tekton-pipelines>
 $ kubectl get secret -n $NAMESPACE signing-secrets -o jsonpath='{.data.cosign\.pub}' | base64 -d > cosign.pub
 ```
 
-### Get the Signing Secret
+### Get the Signing Secret \{#get-the-signing-secret}
 
 ```shell
 $ export NAMESPACE=<tekton-pipelines>
@@ -86,4 +86,3 @@ tekton-chains-controller-55876dfbbd-5wv5z   1/1     Running   0          1m30s
 
 - [Tekton Chains Authentication](https://tekton.dev/docs/chains/authentication/)
 - [Tekton Chains Configuration](https://tekton.dev/docs/chains/config/)
-
diff --git a/docs/en/chains/how_to/image_signature_verification.mdx b/docs/en/chains/how_to/image_signature_verification.mdx
@@ -76,7 +76,7 @@ These steps are identical to the [Quick Start: Signed Provenance](../quick_start
 At [Step 8: Verifying the Image and Attestation](../quick_start/signed_provenance.mdx#step-8-verifying-the-image-and-attestation), we use `cosign` CLI to verify the signature.
 Here we use Kyverno to verify the signature.
 
-#### Step 8.1: Create a Kyverno policy to allow only signed images to be deployed
+#### Step 8.1: Create a Kyverno policy to allow only signed images to be deployed \{#step-81-create-a-kyverno-policy-to-allow-only-signed-images-to-be-deployed}
 
 :::tip
 This step requires cluster administrator privileges.
@@ -267,4 +267,4 @@ This guide provides a foundation for implementing supply chain security in your
 ## References
 
 - [Chains Signed Provenance Tutorial](https://tekton.dev/docs/chains/signed-provenance-tutorial/)
-- [Chains Configuration](../configure/chains_configuration)
+- [Chains Configuration](../configure/chains_configuration)
diff --git a/docs/en/chains/how_to/sbom_verification.mdx b/docs/en/chains/how_to/sbom_verification.mdx
@@ -265,7 +265,7 @@ spec:
 - 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.
-    - `secret.secretName`: The signing secret prepared in the previous step [Get the signing secret](#get-the-signing-secret). But you need to create a new secret with the same namespace as the pipeline run.
+    - `secret.secretName`: The signing secret prepared in the previous step [Get the signing secret](../configure/signing_key_configuration.mdx#get-the-signing-secret). But you need to create a new secret with the same namespace as the pipeline run.
 :::
 
 Save into a yaml file named `chains-demo-5.pipelinerun.yaml` and apply it with:
@@ -585,4 +585,4 @@ This guide provides a foundation for implementing supply chain security in your
 ## References
 
 - [Chains Signed Provenance Tutorial](https://tekton.dev/docs/chains/signed-provenance-tutorial/)
-- [Chains Configuration](../configure/chains_configuration)
+- [Chains Configuration](../configure/chains_configuration)
diff --git a/docs/en/chains/how_to/vulnerability_scanning_verification.mdx b/docs/en/chains/how_to/vulnerability_scanning_verification.mdx
@@ -303,7 +303,7 @@ spec:
 - 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.
-    - `secret.secretName`: The signing secret prepared in the previous step [Get the signing secret](#get-the-signing-secret). But you need to create a new secret with the same namespace as the pipeline run.
+    - `secret.secretName`: The signing secret prepared in the previous step [Get the signing secret](../configure/signing_key_configuration.mdx#get-the-signing-secret). But you need to create a new secret with the same namespace as the pipeline run.
 :::
 
 Save into a yaml file named `chains-demo-4.pipelinerun.yaml` and apply it with:
@@ -725,4 +725,4 @@ This guide provides a foundation for implementing supply chain security in your
 ## References
 
 - [Chains Signed Provenance Tutorial](https://tekton.dev/docs/chains/signed-provenance-tutorial/)
-- [Chains Configuration](../configure/chains_configuration)
+- [Chains Configuration](../configure/chains_configuration)
diff --git a/docs/en/chains/quick_start/signed_provenance.mdx b/docs/en/chains/quick_start/signed_provenance.mdx
@@ -51,7 +51,7 @@ Tekton Chains helps you secure your software supply chain by automatically gener
 
 ## Step-by-Step Instructions
 
-### Step 1: Generate Signing Keys
+### Step 1: Generate Signing Keys \{#step-1-generate-signing-keys}
 
 :::tip
 For more details, please refer to [Signing Key Configuration](../configure/signing_key_configuration)
@@ -82,7 +82,7 @@ Tekton Chains uses cryptographic keys to sign artifacts. By default, it looks fo
    signing-secrets   Opaque   3      3m
    ```
 
-### Step 2: Set up Authentication
+### Step 2: Set up Authentication \{#step-2-set-up-authentication}
 
 :::tip
 For more details, please refer to [Authentication for Chains](../configure/authentication_for_chains)
@@ -115,7 +115,7 @@ Configure registry credentials for image pushing:
      -p "{\"secrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE
    ```
 
-### Step 3: Configure Tekton Chains
+### Step 3: Configure Tekton Chains \{#step-3-configure-tekton-chains}
 
 :::tip
 For more details, please refer to [Chains Configuration](../configure/chains_configuration)
@@ -138,7 +138,7 @@ $ kubectl patch tektonconfigs.operator.tekton.dev config --type=merge -p='{
 }'
 ```
 
-### Step 4: Create a Sample Pipeline
+### Step 4: Create a Sample Pipeline \{#step-4-create-a-sample-pipeline}
 
 This is a Pipeline resource, which is used to build the image and generate the SLSA Provenance attestation.
 
@@ -268,7 +268,7 @@ $ export NAMESPACE=<default>
 $ kubectl apply -n $NAMESPACE -f chains.demo-1.pipeline.yaml
 ```
 
-### Step 5: Run a Sample Pipeline
+### Step 5: Run a Sample Pipeline \{#step-5-run-a-sample-pipeline}
 
 This is a PipelineRun resource, which is used to run the pipeline.
 
@@ -334,7 +334,7 @@ $ kubectl get pipelinerun -n $NAMESPACE -w
 chains-demo-1-<xxxxx>   True        Succeeded   2m         2m
 ```
 
-### Step 6: Wait for the PipelineRun to be signed
+### Step 6: Wait for the PipelineRun to be signed \{#step-6-wait-for-the-pipelinerun-to-be-signed}
 
 Wait for the PipelineRun has `chains.tekton.dev/signed: "true"` annotation.
 
@@ -349,7 +349,7 @@ $ kubectl get pipelinerun -n $NAMESPACE $PIPELINERUN_NAME -o yaml | grep "chains
 
 Once the PipelineRun has `chains.tekton.dev/signed: "true"` annotation, means the image is signed.
 
-### Step 7: Get the image from the PipelineRun
+### Step 7: Get the image from the PipelineRun \{#step-7-get-the-image-from-the-pipelinerun}
 
 ```shell
 # Get the image URI
@@ -369,7 +369,7 @@ $ echo $IMAGE
 
 This image will be used to verify the signature.
 
-### Step 8: Verifying the Image and Attestation
+### Step 8: Verifying the Image and Attestation \{#step-8-verifying-the-image-and-attestation}
 
 1. Get the Signing Public Key
 
diff --git a/docs/en/configure/pod_template_guide.mdx b/docs/en/configure/pod_template_guide.mdx
@@ -66,7 +66,7 @@ Pod templates are useful in the following scenarios:
 - **Network Configuration**: Configure DNS policies and network settings
 - **Consistency**: Ensure consistent execution environments across multiple Pipeline executions
 
-## Which Configuration Method to Choose
+## Which Configuration Method to Choose \{#which-configuration-method-to-choose}
 
 Use this decision guide to quickly determine which configuration method fits your needs:
 
@@ -78,11 +78,11 @@ Use this decision guide to quickly determine which configuration method fits you
 | Different tasks in the same pipeline need different configurations | [Method 3: TaskRunSpecs](#method-3-pipelinerun-taskrunspecs-configuration) | Fine-grained control per task. Useful for mixed workloads (official + custom Tasks). |
 | Set baseline configuration for all pipelines in the cluster | [Method 4: Global (TektonConfig)](#method-4-global-default-configuration-tektonconfig) | Apply once, affects all executions. Good for security defaults, image pull secrets. |
 
-## How to Configure Pod Templates
+## How to Configure Pod Templates \{#how-to-configure-pod-templates}
 
 Pod templates can be configured at four different levels, each serving different purposes and having different scopes of impact.
 
-### Method 1: TaskRun Level Configuration
+### Method 1: TaskRun Level Configuration \{#method-1-taskrun-level-configuration}
 
 Configure Pod template directly in a TaskRun. This affects only the specific TaskRun execution.
 
@@ -107,7 +107,7 @@ spec:
       disktype: ssd
 ```
 
-### Method 2: PipelineRun Level Configuration
+### Method 2: PipelineRun Level Configuration \{#method-2-pipelinerun-level-configuration}
 
 Configure Pod template at the PipelineRun level. This affects all Tasks within the PipelineRun unless overridden by taskRunSpecs.
 
@@ -135,7 +135,7 @@ spec:
         - name: private-registry-secret
 ```
 
-### Method 3: PipelineRun TaskRunSpecs Configuration
+### Method 3: PipelineRun TaskRunSpecs Configuration \{#method-3-pipelinerun-taskrunspecs-configuration}
 
 Configure Pod template for specific Tasks within a PipelineRun. This allows fine-grained control over individual Tasks in a Pipeline.
 
@@ -174,7 +174,7 @@ spec:
           environment: production
 ```
 
-### Method 4: Global Default Configuration (TektonConfig)
+### Method 4: Global Default Configuration (TektonConfig) \{#method-4-global-default-configuration-tektonconfig}
 
 Configure a global default Pod template that applies to all TaskRuns and PipelineRuns in the cluster.
 
@@ -340,7 +340,7 @@ spec:
             effect: "NoSchedule"
 ```
 
-### Example 4: Override for Custom Images Requiring Root Access
+### Example 4: Override for Custom Images Requiring Root Access \{#example-4-override-for-custom-images-requiring-root-access}
 
 **Scenario**: Your global default uses secure non-root user (65532), but you have a pipeline with custom images that require root access. Use TaskRunSpecs to override for specific tasks while maintaining secure defaults for official Tasks.
 
@@ -383,7 +383,7 @@ spec:
 
 **Best Practice**: Only override `runAsUser` to `0` for specific tasks that truly require root access. Let official Tekton Tasks use the secure default (65532).
 
-### Example 5: Using Official Tasks with Legacy Global Configuration
+### Example 5: Using Official Tasks with Legacy Global Configuration \{#example-5-using-official-tasks-with-legacy-global-configuration}
 
 **Scenario**: You migrated from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines and set the global `default-pod-template` to `runAsUser: 0` for backward compatibility with existing custom images. Now you want to use official Tekton catalog Tasks, which require `runAsUser: 65532` and `fsGroup: 65532`.
 
@@ -480,7 +480,7 @@ spec:
 
 ## Important Considerations
 
-### Common Pitfalls
+### Common Pitfalls \{#common-pitfalls}
 
 These are the most common issues users encounter. Review these before configuring Pod templates:
 
@@ -532,7 +532,7 @@ These are the most common issues users encounter. Review these before configurin
 
 6. **Test Configuration Changes**: Test Pod template configuration changes in non-production environments before applying to production, especially security context changes.
 
-## Verification
+## Verification \{#verification}
 
 After applying Pod template configurations, verify they are effective:
 
diff --git a/docs/en/hub/concepts/understanding_tekton_hub.mdx b/docs/en/hub/concepts/understanding_tekton_hub.mdx
@@ -42,7 +42,7 @@ Tekton Hub addresses these challenges by providing a centralized platform that:
 
 By centralizing resource discovery and management, Tekton Hub promotes reusability, standardization, and collaboration across the Tekton ecosystem.
 
-## Advantages
+## Advantages \{#advantages}
 
 - **Simplified Discovery**: Easy-to-use web interface for finding Tekton resources
 - **Improved Reusability**: Promotes sharing and reuse of well-tested components
@@ -74,9 +74,9 @@ A developer creates a useful Task for a specific tool and wants to share it with
 - Custom catalogs need to be manually added to the configuration
 - Resources are limited to those available in configured catalogs
 
-## Principles
+## Principles \{#principles}
 
-### Architecture
+### Architecture \{#architecture}
 
 Tekton Hub consists of three main components:
 
@@ -86,7 +86,7 @@ Tekton Hub consists of three main components:
 
 The API Service communicates with the database to store and retrieve information about resources, and catalogs. It periodically refreshes catalog data to ensure that the latest resources are available.
 
-### Resource Management Workflow
+### Resource Management Workflow \{#resource-management-workflow}
 
 1. **Catalog Registration**: Catalogs are registered in the Tekton Hub configuration
 2. **Catalog Refresh**: The system periodically scans catalogs for new or updated resources
@@ -98,4 +98,3 @@ The API Service communicates with the database to store and retrieve information
 
 - [Tekton Hub GitHub Repository](https://github.com/tektoncd/hub)
 - [Tekton Catalog Organization TEP](https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md)
-
diff --git a/docs/en/hub/configure/custom-catalogs.mdx b/docs/en/hub/configure/custom-catalogs.mdx
@@ -207,7 +207,7 @@ $ kubectl create secret generic tekton-hub-api-ssh-crds \
 - The secret must be created in the same namespace as your Tekton Hub installation
 - Include all three files: private key, public key, and known_hosts
 
-#### Generating known_hosts Entries
+#### Generating known_hosts Entries \{#generating-known_hosts-entries}
 
 **Important**: You must generate the `known_hosts` file by actually connecting to the Git server to capture its SSH fingerprint. Simply copying example entries may not work due to server key changes or different Git providers.
 
diff --git a/docs/en/hub/configure/tekton-hub-config.mdx b/docs/en/hub/configure/tekton-hub-config.mdx
@@ -58,7 +58,7 @@ data:
   CATALOG_REFRESH_INTERVAL: "0"
 ```
 
-## Categories Configuration
+## Categories Configuration \{#categories-configuration}
 
 ### Default Categories
 
@@ -153,7 +153,7 @@ metadata:
     tekton.dev/categories: "Build Tools,Continuous Integration"
 ```
 
-## Hub Resolver Configuration
+## Hub Resolver Configuration \{#hub-resolver-configuration}
 
 The `Hub` resolver enables users to reference `Hub` resources in `TaskRuns` and `PipelineRuns`. Proper configuration is essential for catalog resource resolution.
 
diff --git a/docs/en/overview/release_notes.mdx b/docs/en/overview/release_notes.mdx
@@ -13,7 +13,7 @@ title: Release Notes
 The maintenance period for version **`v4.2.x`** is from 15 Aug, 2025 to 15 Aug, 2026.
 :::
 
-## Compatibility and support matrix
+## Compatibility and support matrix \{#compatibility-and-support-matrix}
 
 The following table shows the compatibility and support matrix between the `Alauda DevOps Pipelines` operator and `ACP` versions.
 
@@ -219,4 +219,4 @@ The following upstream issues from the Tekton community have been resolved in th
 
 ### Known Issues
 
-{/* release-notes-for-bugs?template=unfixed&project=DEVOPS&version=v4.2.0 */}
+{/* release-notes-for-bugs?template=unfixed&project=DEVOPS&version=v4.2.0 */}
diff --git a/docs/en/results/configure/database_configuration.mdx b/docs/en/results/configure/database_configuration.mdx
diff --git a/docs/en/results/quick_start.mdx b/docs/en/results/quick_start.mdx
diff --git a/package.json b/package.json
diff --git a/yarn.lock b/yarn.lock
