# Migrating from `Alauda DevOps Tekton v3` to `Alauda DevOps Pipelines` (v4)

:::tip

* In this document, `v3` refers to `Tekton Operator` or `Alauda DevOps Tekton v3`, and `v4` refers to `Alauda DevOps Pipelines`.
  :::

:::note

* **This guide is specifically for migrating from `v3` to `v4`.** For upgrading between `v4` versions, please refer to the Pipelines upgrade documentation.
  :::

This guide provides detailed steps for smoothly migrating from `v3` to `v4`. The upgrade process is designed as a seamless migration to ensure your existing `CI/CD` pipelines remain unaffected.

## Migration Steps

### 1. Uninstall Existing Tekton Pipeline Instance and `Alauda DevOps Tekton v3`

Before starting the upgrade, you need to uninstall the existing Tekton components. Follow these steps:

> **Important Note:** The uninstallation process will not affect your existing Task, TaskRun, Pipeline, and PipelineRun resources. These resources will remain unchanged after the upgrade is complete.

1. **Delete Pipeline Instance**

   ```bash
   $ kubectl delete tektonpipelines.operator.tekton.dev pipeline
   ```

2. **Verify Pipeline Instance Deletion**

   ```bash
   $ kubectl get tektonpipelines.operator.tekton.dev pipeline
   ```

   Ensure the command returns no resources, indicating successful deletion.

3. **Uninstall Tekton Operator**

   ```bash
   $ kubectl delete subscriptions.operators.coreos.com tekton-operator -n tekton-operator
   ```

4. **Verify Operator Uninstallation**

   ```bash
   $ kubectl get subscriptions.operators.coreos.com -A | grep tekton
   ```

   Ensure the command returns no results, indicating successful uninstallation.

### 2. Deploy `Alauda DevOps Pipelines` (v4)

1. Navigate to your cluster's `Administrator` -> `Application Market Management` -> `OperatorHub` page
2. Search for and select **Alauda DevOps Pipelines**
3. Choose the appropriate Channel
   :::warning

* **You can only select versions for installation in the `pipelines-4.0` Channel.**

  This is because the `Pipeline` component versions in other Channels are higher, which may cause incompatibility with the original `CI/CD` system.
  :::

4. Follow the on-screen instructions to complete the deployment
5. **Wait for `Alauda DevOps Pipelines` Operator to be Ready**

   After the `Alauda DevOps Pipelines` Operator deployment is complete, it will automatically deploy related components such as `Pipelines`. You can check the component status using the following commands:

   ```bash
   $ kubectl get tektonconfigs.operator.tekton.dev config

   $ kubectl get tektonpipelines.operator.tekton.dev pipeline
   ```

   Wait until both resources show a `Ready` status before proceeding to the next step.

:::note

* If you previously used `Tekton` only in `Alauda Container Platform Builds`, you can skip the following steps and use the default configuration of `Alauda DevOps Pipelines` directly.
  :::

### 3. Configure TektonConfig

:::note

* If you previously used `Tekton` only in `Alauda Container Platform Builds`, you can skip the following steps and use the default configuration of `Alauda DevOps Pipelines` directly.
  :::

After the Alauda DevOps Pipelines Operator deployment is complete, you need to configure the `TektonConfig` resource to ensure compatibility with your existing system:

> **Best Practice:** It is recommended to only modify the `spec.pipeline` section configuration to maintain system stability.

```yaml
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    await-sidecar-readiness: true
    disable-creds-init: false
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-custom-tasks: true
    enable-git-resolver: true
    enable-hub-resolver: true
    enable-provenance-in-status: true
    enable-step-actions: true
    enforce-nonfalsifiability: none
    keep-pod-on-cancel: false
    metrics.count.enable-reason: false
    metrics.pipelinerun.duration-type: histogram
    metrics.pipelinerun.level: pipeline
    metrics.taskrun.duration-type: histogram
    metrics.taskrun.level: task

    performance:
      disable-ha: false
    require-git-ssh-secret-known-hosts: false
    running-in-environment-with-injected-sidecars: true
    send-cloudevents-for-runs: false
    set-security-context: false
    trusted-resources-verification-no-match-policy: ignore

    # Tekton Operator compatibility configuration
    coschedule: workspaces
    disable-affinity-assistant: true
    enable-api-fields: alpha
    enable-cel-in-whenexpression: true
    enable-param-enum: true
    max-result-size: 8192
    results-from: sidecar-logs

    options:
      disabled: false
      configMaps:
        # Modify default configuration: init container quotas, runAsUser, image pull timeout
        config-defaults:
          data:
            # Container configuration
            default-imagepullbackoff-timeout: 5m
            default-pod-template: |
              securityContext:
                runAsUser: 0

            # Resource quota configuration
            default-container-resource-requirements: |
              place-scripts: # Update 'place-scripts' container resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "128Mi"
                  cpu: "100m"

              prepare: # Update 'prepare' container resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "256Mi"
                  cpu: "100m"

              working-dir-initializer: # Update 'working-dir-initializer' container resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "512Mi"
                  cpu: "100m"

              prefix-scripts: # Update containers starting with 'scripts-' resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "128Mi"
                  cpu: "100m"

              prefix-sidecar-scripts: # Update containers starting with 'sidecar-scripts-' resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "128Mi"
                  cpu: "100m"

              sidecar-tekton-log-results: # Update 'sidecar-tekton-log-results' container resource requirements
                requests:
                  memory: "64Mi"
                  cpu: "50m"
                limits:
                  memory: "128Mi"
                  cpu: "100m"

  addon: {}
  chain:
    artifacts.oci.format: simplesigning
    artifacts.oci.storage: oci
    artifacts.pipelinerun.format: in-toto
    artifacts.pipelinerun.storage: oci
    artifacts.taskrun.format: in-toto
    artifacts.taskrun.storage: oci
    disabled: false
    options: {}
  config: {}
  dashboard:
    options: {}
    readonly: false
  hub:
    options: {}

  platforms:
    openshift: {}
  profile: all
  pruner:
    disabled: false
    keep: 100
    resources:
    - pipelinerun
    schedule: 0 8 * * *
  targetNamespace: tekton-pipelines
  trigger:
    enable-api-fields: stable
    options: {}
```

### 4. Configure Log Access Permissions

:::note

* If you previously used `Tekton` only in `Alauda Container Platform Builds`, you can skip the following steps and use the default configuration of `Alauda DevOps Pipelines` directly.
  :::

Since the `results-from: sidecar-logs` feature is enabled, you need to configure log access permissions for the controller:

> **Technical Note:** This configuration allows the controller to retrieve results information from pod logs. For detailed information, please refer to the [Tekton official documentation](https://github.com/tektoncd/pipeline/tree/main/optional_config/enable-log-access-to-controller).

```bash
kubectl apply -f - <<EOF
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tekton-pipelines-controller-pod-log-access
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
rules:
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tekton-pipelines-controller-pod-log-access
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
subjects:
  - kind: ServiceAccount
    name: tekton-pipelines-controller
    namespace: tekton-pipelines
roleRef:
  kind: ClusterRole
  name: tekton-pipelines-controller-pod-log-access
  apiGroup: rbac.authorization.k8s.io
EOF
```

## Migration Complete

After completing the above steps, you have successfully migrated from `Tekton Operator` (v3) to `Alauda DevOps Pipelines` (v4). The new version provides:

* Enhanced system stability
* Richer feature set
* Better performance
* More flexible configuration options

We recommend reviewing the `Alauda DevOps Pipelines` documentation to understand all the features the new version offers and take full advantage of its capabilities.