📚 Sync docs from alaudadevops/tektoncd-operator on 7d9ec4c8d0bf8777aedfb3d6a046a7dc788ea1b6

edge-katanomi-app2[bot] · edge-katanomi-app2[bot] · commit 376866d1296c · 2025-12-23T10:18:46.000Z
Source: docs: [DEVOPS-43043] remove docker in docs for release-4.4 (#1033) Author: yzc Ref: refs/heads/release-4.4 Commit: 7d9ec4c8d0bf8777aedfb3d6a046a7dc788ea1b6 This commit automatically syncs documentation changes from the source-docs repository. 🔗 View source commit: https://github.com/alaudadevops/tektoncd-operator/commit/7d9ec4c8d0bf8777aedfb3d6a046a7dc788ea1b6 🤖 Synced on 2025-12-23 10:18:46 UTC
diff --git a/.github/SYNC_INFO.md b/.github/SYNC_INFO.md
@@ -1,10 +1,10 @@
 # Documentation Sync Information
 
-- **Last synced**: 2025-10-16 03:35:39 UTC
+- **Last synced**: 2025-12-23 10:18:46 UTC
 - **Source repository**: alaudadevops/tektoncd-operator
-- **Source commit**: [05ad4d35338f17a79c11d7e998fb35850936be7d](https://github.com/alaudadevops/tektoncd-operator/commit/05ad4d35338f17a79c11d7e998fb35850936be7d)
+- **Source commit**: [7d9ec4c8d0bf8777aedfb3d6a046a7dc788ea1b6](https://github.com/alaudadevops/tektoncd-operator/commit/7d9ec4c8d0bf8777aedfb3d6a046a7dc788ea1b6)
 - **Triggered by**: edge-katanomi-app2[bot]
-- **Workflow run**: [#87](https://github.com/alaudadevops/tektoncd-operator/actions/runs/18549473073)
+- **Workflow run**: [#127](https://github.com/alaudadevops/tektoncd-operator/actions/runs/20458014001)
 
 ## Files synced:
 - docs/
diff --git a/docs/en/chains/configure/authentication_for_chains.mdx b/docs/en/chains/configure/authentication_for_chains.mdx
@@ -27,7 +27,7 @@ To push to an OCI registry, the Chains controller will look for credentials in t
 
 #### Create a Secret based on existing credentials
 
-If you already ran `docker login`, you can copy the credentials stored in config.json into Kubernetes.
+If you already ran `podman login`, you can copy the credentials stored in config.json into Kubernetes.
 
 :::note
 Make sure that any external credentials store, such as the native keychain of the operating system, is not used to store the credentials and the config.json is of the format:
@@ -46,15 +46,15 @@ Make sure that any external credentials store, such as the native keychain of th
 Create a secret with config.json:
 
 ```shell
-kubectl create secret generic docker-registry \
+kubectl create secret generic registry-credentials \
     --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
     --type=kubernetes.io/dockerconfigjson \
     -n $NAMESPACE
 ```
 
 #### Create a Secret by providing credentials on the command line
 
-First, you will need access to credentials for your registry (they are in a file called `credentials.json` in this example). Then, create a Docker config type Kubernetes secret:
+First, you will need access to credentials for your registry (they are in a file called `credentials.json` in this example). Then, create a `kubernetes.io/dockerconfigjson` type Kubernetes secret:
 
 ```shell
 kubectl create secret docker-registry registry-credentials \
diff --git a/docs/en/chains/how_to/sbom_verification.mdx b/docs/en/chains/how_to/sbom_verification.mdx
@@ -199,7 +199,7 @@ spec:
     - name: source
       description: The workspace for source code.
     - name: dockerconfig
-      description: The workspace for Docker configuration.
+      description: The workspace for distribution registry configuration.
     - name: signkey
       description: The workspace for private keys and passwords used for image signatures.
 ```
diff --git a/docs/en/chains/how_to/source_code_repository_verification.mdx b/docs/en/chains/how_to/source_code_repository_verification.mdx
@@ -221,7 +221,7 @@ spec:
     - name: source
       description: The workspace for source code.
     - name: dockerconfig
-      description: The workspace for Docker configuration.
+      description: The workspace for distribution registry configuration.
 ```
 
 :::tip
diff --git a/docs/en/chains/how_to/vulnerability_scanning_verification.mdx b/docs/en/chains/how_to/vulnerability_scanning_verification.mdx
@@ -233,7 +233,7 @@ spec:
     - name: source
       description: The workspace for source code.
     - name: dockerconfig
-      description: The workspace for Docker configuration.
+      description: The workspace for distribution registry configuration.
     - name: signkey
       description: The workspace for private keys and passwords used for image signatures.
 ```
diff --git a/docs/en/chains/quick_start/signed_provenance.mdx b/docs/en/chains/quick_start/signed_provenance.mdx
@@ -226,7 +226,7 @@ spec:
     - name: source
       description: The workspace for source code.
     - name: dockerconfig
-      description: The workspace for Docker configuration.
+      description: The workspace for distribution registry configuration.
 ```
 
 :::tip
@@ -251,7 +251,7 @@ In production environments, you should:
   - This format is compliant with Tekton Chains, see [Tekton Chains Type Hinting](../concepts/understanding_tekton_chains.mdx#type-hinting) in above section for more details.
 - `workspaces`: The workspaces for the pipeline.
   - `source`: The workspace for source code.
-  - `dockerconfig`: The workspace for Docker configuration.
+  - `dockerconfig`: The workspace for distribution registry configuration.
 :::
 
 **Need to adjust the configuration**
@@ -303,7 +303,7 @@ spec:
 - `taskRunTemplate`: The task run template.
   - `serviceAccountName`: The service account to use for the pipeline.
 - `workspaces`: The workspaces for the pipeline.
-  - `dockerconfig`: The workspace for Docker configuration.
+  - `dockerconfig`: The workspace for distribution registry configuration.
   - `source`: The workspace for source code.
 :::
 
diff --git a/docs/en/development/component-quickstart/index.md b/docs/en/development/component-quickstart/index.md
@@ -267,7 +267,7 @@ Ref : <https://github.com/AlaudaDevops/tektoncd-pipeline/blob/main/.tekton/tp-al
 3. **Image Build Phase**
    - Build multiple component images in parallel (e.g., tkn, proxy, webhook, operator)
    - Each image build includes:
-     - Build Docker images
+     - Build OCI images
      - Update image tag in `values.yaml` and `config` directory
 
 4. **Artifact Upload Phase**
diff --git a/docs/en/development/run_e2e.mdx b/docs/en/development/run_e2e.mdx
@@ -13,7 +13,7 @@ Before starting, please ensure your environment meets the following requirements
 
 ### 1. System Requirements
 - Linux or macOS operating system
-- Docker installed and running
+- Podman installed
 - At least 4GB available memory
 - At least 10GB available disk space
 
@@ -23,19 +23,19 @@ Before starting, please ensure your environment meets the following requirements
 - Cluster version: Kubernetes 1.19+
 
 ### 3. Tool Requirements
-- `docker` command-line tool
+- `podman` command-line tool
 - `allure` optional test report reading tool
 
 ## Quick Start
 
 ### Step 1: Prepare Test Environment
 
 ```bash
-# Check Docker version
-docker version
+# Check podman version
+podman version
 
 # Pull the E2E test image
-docker pull registry.alauda.cn:60070/devops/tektoncd/e2e/operator/operator-e2e:latest
+podman pull registry.alauda.cn:60070/devops/tektoncd/e2e/operator/operator-e2e:latest
 ```
 
 > **Note**: The test image is built from the Dockerfile located at `.tekton/dockerfiles/operator-e2e.Dockerfile`.
@@ -90,7 +90,7 @@ toolchains:
     testGroup:
       # Default test group
       default: e2e-automation
-    # Base64 encoded Docker configuration file
+    # Base64 encoded distribution registry configuration file
     dockerConfig: <BASE64_ENCODED_DOCKER_CONFIG>
 
   nexus:
@@ -238,7 +238,7 @@ Each toolchain contains the following common configuration items:
 - `token`: Admin user access token
 
 **Harbor**:
-- `dockerConfig`: Base64 encoded Docker configuration file
+- `dockerConfig`: Base64 encoded distribution registry configuration file
 
 **SonarQube**:
 - `token`: Admin user access token
@@ -267,7 +267,7 @@ Each toolchain contains the following common configuration items:
 ### Step 3: Run E2E Tests
 
 ```bash
-docker run --entrypoint /bin/bash -it \
+podman run --entrypoint /bin/bash -it \
   -e TESTING_CONFIG=/tmp/workspace/config.yaml \
   -e KUBECONFIG=/tmp/workspace/config \
   -v ${PWD}/workspace:/tmp/workspace \
@@ -334,7 +334,7 @@ allure open allure-report/
    curl -I registry.alauda.cn:60070
 
    # Configure image registry authentication
-   docker login registry.alauda.cn:60070
+   podman login registry.alauda.cn:60070
    ```
 
 4. **Test Timeout**
@@ -358,7 +358,7 @@ Enable debug mode to get more detailed logs:
 
 ```bash
 # Run tests with debug mode
-docker run --entrypoint /bin/bash -it \
+podman run --entrypoint /bin/bash -it \
   -e TESTING_CONFIG=/tmp/workspace/config.yaml \
   -e KUBECONFIG=/tmp/workspace/config \
   -e DEBUG=true \
diff --git a/docs/en/hub/tutorials/creating-custom-catalog.mdx b/docs/en/hub/tutorials/creating-custom-catalog.mdx
@@ -91,10 +91,10 @@ metadata:
     tekton.dev/categories: "Build Tools"
 
     # Searchable tags (comma-separated, no spaces after commas)
-    tekton.dev/tags: "build,docker,container"
+    tekton.dev/tags: "build,podman,container"
 
     # Human-readable display name
-    tekton.dev/displayName: "Docker Build Task"
+    tekton.dev/displayName: "Podman Build Task"
 
     # Supported platforms (optional)
     tekton.dev/platforms: "linux/amd64,linux/arm64"
diff --git a/docs/en/hub/tutorials/writing-pipelines.mdx b/docs/en/hub/tutorials/writing-pipelines.mdx
@@ -123,8 +123,8 @@ spec:
   workspaces:
   - name: source-code
     description: Source code workspace
-  - name: docker-config
-    description: Docker registry credentials
+  - name: registry-creds
+    description: Distribution registry credentials
     optional: true
 
   tasks:
@@ -171,7 +171,7 @@ spec:
     - name: source
       workspace: source-code
     - name: dockerconfig
-      workspace: docker-config
+      workspace: registry-creds
 
   finally:
   - name: cleanup
diff --git a/docs/en/hub/tutorials/writing-tasks.mdx b/docs/en/hub/tutorials/writing-tasks.mdx
@@ -53,8 +53,8 @@ metadata:
   annotations:
     tekton.dev/pipelines.minVersion: "0.17.0"  # Minimum Tekton version
     tekton.dev/categories: "Build Tools"       # Hub category
-    tekton.dev/tags: "build,docker,image"     # Hub search tags
-    tekton.dev/displayName: "Build Docker Image"  # Hub display name
+    tekton.dev/tags: "build,podman,image"     # Hub search tags
+    tekton.dev/displayName: "Build Podman Image"  # Hub display name
     tekton.dev/platforms: "linux/amd64,linux/arm64"  # Supported platforms
 ```
 
@@ -102,7 +102,7 @@ metadata:
 
 ### Effective Tagging
 - Use specific, searchable tags
-- Include technology names (`docker`, `kubernetes`, `npm`, etc.)
+- Include technology names (`podman`, `kubernetes`, `npm`, etc.)
 - Add use case tags (ci, cd, build, test, deploy)
 
 ## `Hub` Validation Requirements
diff --git a/docs/en/pipelines/concepts/pod_templates_concept.mdx b/docs/en/pipelines/concepts/pod_templates_concept.mdx
@@ -251,7 +251,7 @@ Pod template configuration supports the fields listed in the table below.
 | automountServiceAccountToken | **Default:** true. Determines whether Tekton automatically provides the token for the service account used by the Pod inside containers at a predefined path.                                                                                                                                                     |
 | dnsPolicy                    | **Default:** ClusterFirst. Specifies the [DNS policy](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy) for the Pod. Legal values are ClusterFirst, Default, and None. Does **not** support ClusterFirstWithHostNet because Tekton Pods cannot run with host networking. |
 | dnsConfig                    | Specifies [additional DNS configuration for the Pod](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-config), such as name servers and search domains.                                                                                                                         |
-| enableServiceLinks           | **Default:** true. Determines whether services in the Pod's namespace are exposed as environment variables to the Pod, similarly to Docker service links.                                                                                                                                                         |
+| enableServiceLinks           | **Default:** true. Determines whether services in the Pod's namespace are exposed as environment variables to the Pod.                                                                                                                                                         |
 | priorityClassName            | Specifies the [priority class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) for the Pod. Allows you to selectively enable preemption on lower-priority workloads.                                                                                                                  |
 | schedulerName                | Specifies the [scheduler](https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/) to use when dispatching the Pod. You can specify different schedulers for different types of workloads, such as volcano.sh for machine learning workloads.                                          |
 | imagePullSecrets             | Specifies the [secret](https://kubernetes.io/docs/concepts/configuration/secret/) to use when [ pulling a container image](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).                                                                                                |
diff --git a/docs/en/pipelines/concepts/stepaction_concept.mdx b/docs/en/pipelines/concepts/stepaction_concept.mdx
@@ -170,14 +170,14 @@ spec:
     - name: context
       type: string
       default: "."
-  image: docker
+  image: podman
   env:
     - name: IMAGE_NAME
       value: $(params.image.name)
     - name: IMAGE_TAG
       value: $(params.image.tag)
   script: |
-    docker build -t $IMAGE_NAME:$IMAGE_TAG $(params.context)
+    podman build -t $IMAGE_NAME:$IMAGE_TAG $(params.context)
 ```
 
 ### Results
diff --git a/docs/en/pipelines/how_to/adjust_dockerfile_for_task_compatible_image.mdx b/docs/en/pipelines/how_to/adjust_dockerfile_for_task_compatible_image.mdx
@@ -27,7 +27,7 @@ The following scenarios require referring to the guidance in this document:
 
 Before using this feature, ensure:
 
-- You have a Docker image building environment
+- You have a OCI image building environment
   - You can use the platform's native build pipeline
   - If you need to use community/open-source tools, ensure you have internet access or have prepared offline packages
 - You have a basic understanding of Dockerfile writing
@@ -43,7 +43,7 @@ First, confirm the release version of the base image, as the command for creatin
 
 ```bash
 # Check the release version of the base image
-$ docker run -it --rm ${registry} cat /etc/os-release
+$ podman run -it --rm ${registry} cat /etc/os-release
 
 # Possible outputs
 NAME="Alpine Linux"
@@ -105,13 +105,13 @@ After building, validate whether the image can run correctly:
 
 ```bash
 # Verify user configuration
-$ docker run -it --rm ${registry} id
+$ podman run -it --rm ${registry} id
 
 # Expected output
 uid=65532(nonroot) gid=65532(nonroot) groups=65532(nonroot)
 
 # Verify application permissions
-$ docker run -it --rm ${registry} ls -la /home/nonroot
+$ podman run -it --rm ${registry} ls -la /home/nonroot
 ```
 
 ## Operation Results
diff --git a/docs/en/pipelines/trouble_shooting/custom_image_pod_creation_failed.mdx b/docs/en/pipelines/trouble_shooting/custom_image_pod_creation_failed.mdx
@@ -47,7 +47,7 @@ If this issue only appears when using custom images, it is recommended to follow
 
 1. Verify if the image itself has issues:
    ```bash
-   $ docker run -it --rm ${registry} ${cmd}
+   $ podman run -it --rm ${registry} ${cmd}
    ```
 
 2. Check the compatibility of the Task configuration with the image:
diff --git a/docs/en/pipelines/trouble_shooting/custom_images_cannot_be_used_in_the_run-script.mdx b/docs/en/pipelines/trouble_shooting/custom_images_cannot_be_used_in_the_run-script.mdx
@@ -50,12 +50,12 @@ If this issue occurs only when using the custom image, it is recommended to trou
 
 1. Verify whether there are insufficient permissions with the image when run as the root user:
    ```bash
-   $ docker run -it --rm --user root ${registry} ${cmd}
+   $ podman run -it --rm --user root ${registry} ${cmd}
    ```
 
 2. Check if the application allows user 65532 to access specific directories or files:
    ```bash
-   $ docker run -it --rm --user 65532:65532 ${registry} ${cmd} ls -la /path/to/directory
+   $ podman run -it --rm --user 65532:65532 ${registry} ${cmd} ls -la /path/to/directory
    ```
 
 3. Check the securityContext configuration of the Task:
diff --git a/docs/en/teps/0001_triggertemplate_runtime_config.md b/docs/en/teps/0001_triggertemplate_runtime_config.md
@@ -322,7 +322,7 @@ spec:
           - name: image-tag
             value: "latest"
           - name: registry
-            value: "docker.io"
+            value: "ghcr.io"
         # workspaces merged by name field
         workspaces:
           - name: source
@@ -429,7 +429,7 @@ spec:
     - name: image-tag
       value: "latest" # From base config, unchanged
     - name: registry
-      value: "docker.io" # From base config, unchanged
+      value: "ghcr.io" # From base config, unchanged
     - name: build-type
       value: "optimized" # From additional config, newly added
   # workspaces merge result - merged by name
diff --git a/docs/en/tutorials/helm/deploy_or_upgrade_by_helm_chart_in_registry.mdx b/docs/en/tutorials/helm/deploy_or_upgrade_by_helm_chart_in_registry.mdx
@@ -28,7 +28,7 @@ You'll Build a reusable Pipeline named `helm-oci-deploy` that:
 * An OCI registry with the OCI chart reference and version you intend to deploy, e.g.:
     * `oci://registry.example.com/charts/myapp`
     * Version like `1.2.3` (must exist in the registry)
-* Registry credentials for your OCI registry as a Docker config JSON:
+* Registry credentials for your OCI registry as a `Secret` of `kubernetes.io/dockerconfigjson` type:
     * Create a Kubernetes Secret of type `kubernetes.io/dockerconfigjson` (example below).
 * Cluster access for Helm (choose one):
     * Mount a Kubeconfig Secret,
@@ -38,7 +38,7 @@ You'll Build a reusable Pipeline named `helm-oci-deploy` that:
 
 ### Step 1: Create the Registry Credential Secret
 
-You need a registry credential for your OCI registry as a Docker config JSON.
+You need a registry credential for your OCI registry as a `Secret` of `kubernetes.io/dockerconfigjson` type.
 
 You can refer to the [Prepare Registry Credential](../prepare/prepare_registry_credential.mdx).
 
@@ -97,7 +97,7 @@ spec:
       default: ""
   workspaces:
     - name: registry-creds
-      description: Workspace with docker config at config.json (for OCI auth)
+      description: Workspace with distribution registry config at config.json (for OCI auth)
       optional: true
     - name: kubeconfig
       description: Workspace containing kubeconfig file at ./kubeconfig
diff --git a/docs/en/tutorials/helm/package_and_push_helm_chart.mdx b/docs/en/tutorials/helm/package_and_push_helm_chart.mdx
@@ -28,20 +28,20 @@ You will create a Pipeline with two Tasks:
 * Tekton Pipelines installed on your cluster.
 * A Helm 3.8+ container image (Helm v3 with OCI support).
 * An OCI registry and repository path (e.g., oci://registry.example.com/charts).
-* Push credentials for your OCI registry as a Docker config JSON:
+* Push credentials for your OCI registry as a `Secret` of `kubernetes.io/dockerconfigjson` type:
     * Create a Kubernetes Secret of type `kubernetes.io/dockerconfigjson` (example below).
 * A Git repository that contains a valid Helm chart (directory with `Chart.yaml`, `templates/`, `values.yaml`).
 * Git access to the repository:
     * Public repo: nothing special.
     * Private repo: create a Git credential Secret (SSH or basic-auth).
 
-Why Docker config JSON? Helm uses the same auth config as Docker. We'll point Helm to it via `HELM_REGISTRY_CONFIG`.
+Why `Secret` of `kubernetes.io/dockerconfigjson` type? We'll point Helm to distribution registry via `HELM_REGISTRY_CONFIG`.
 
 ## Step-by-Step Instructions
 
 ### Step 1: Create the Registry Credential Secret
 
-You need a registry credential for your OCI registry as a Docker config JSON.
+You need a registry credential for your OCI registry as a `Secret` of `kubernetes.io/dockerconfigjson` type.
 
 You can refer to the [Prepare Registry Credential](../prepare/prepare_registry_credential.mdx).
 
diff --git a/docs/en/tutorials/java/use-java-image-build-scan-deploy-pipeline.mdx b/docs/en/tutorials/java/use-java-image-build-scan-deploy-pipeline.mdx
diff --git a/docs/en/tutorials/python/use-python-image-build-scan-deploy-pipeline.mdx b/docs/en/tutorials/python/use-python-image-build-scan-deploy-pipeline.mdx
