📚 Sync docs from alaudadevops/tektoncd-operator on 30806f63ba2a1b166f84307d049ff51a6b1fe3c3

Source: update v4.0 EOL:2026-12-08 (#1541)
Author: zhoub
Ref: refs/heads/release-4.8
Commit: 30806f63ba2a1b166f84307d049ff51a6b1fe3c3

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

🔗 View source commit: AlaudaDevops/tektoncd-operator@30806f6
🤖 Synced on 2026-04-03 01:45:50 UTC

Author: l-qing

.github/SYNC_INFO.md

@@ -1,10 +1,10 @@
 # Documentation Sync Information
 
-- **Last synced**: 2026-04-02 07:27:43 UTC
+- **Last synced**: 2026-04-03 01:45:50 UTC
 - **Source repository**: alaudadevops/tektoncd-operator
-- **Source commit**: [d3fad91b6261d92fa5a375a7110f3042a558a358](https://github.com/alaudadevops/tektoncd-operator/commit/d3fad91b6261d92fa5a375a7110f3042a558a358)
-- **Triggered by**: edge-katanomi-app2[bot]
-- **Workflow run**: [#175](https://github.com/alaudadevops/tektoncd-operator/actions/runs/23889234790)
+- **Source commit**: [30806f63ba2a1b166f84307d049ff51a6b1fe3c3](https://github.com/alaudadevops/tektoncd-operator/commit/30806f63ba2a1b166f84307d049ff51a6b1fe3c3)
+- **Triggered by**: l-qing
+- **Workflow run**: [#176](https://github.com/alaudadevops/tektoncd-operator/actions/runs/23930121635)
 
 ## Files synced:
 - docs/

.yarn/releases/yarn-4.10.3.cjs

@@ -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-attestation}
+### Custom metadata
 
 Custom metadata can be added as needed to support specific security requirements.
 
@@ -130,5 +130,3 @@ Storage backends are where Tekton Chains stores the generated provenance and sig
 ## Controller
 
 The Tekton Chains controller is the core component that observes TaskRun and PipelineRun executions, captures relevant information, and generates, signs, and stores provenance. It runs as a Kubernetes deployment in the `tekton-pipelines` namespace.
-
-<a id="custom-metadata-attestation"></a>

.yarn/releases/yarn-4.13.0.cjs

@@ -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)

docs/en/chains/concepts/core_concepts.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:
 
@@ -137,4 +137,3 @@ signers.x509.fulcio.address: <"http://fulcio.fulcio-system.svc">
 
 - [Tekton Chains Authentication](https://tekton.dev/docs/chains/authentication/)
 - [Tekton Chains Configuration](https://tekton.dev/docs/chains/config/)
-

docs/en/chains/concepts/understanding_tekton_chains.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,3 +86,4 @@ 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/)
+

docs/en/chains/configure/authentication_for_chains.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-81-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
 
 :::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)

docs/en/chains/configure/signing_key_configuration.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](../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.
+    - `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.
 :::
 
 Save into a yaml file named `chains-demo-5.pipelinerun.yaml` and apply it with:
@@ -585,5 +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)
-<a id="get-the-signing-secret"></a>
+- [Chains Configuration](../configure/chains_configuration)

docs/en/chains/how_to/image_signature_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](../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.
+    - `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.
 :::
 
 Save into a yaml file named `chains-demo-4.pipelinerun.yaml` and apply it with:
@@ -725,5 +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)
-<a id="get-the-signing-secret"></a>
+- [Chains Configuration](../configure/chains_configuration)