#Migrating from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines

This guide provides detailed steps for smoothly migrating from Alauda DevOps Tekton v3 to Alauda DevOps Pipelines. 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

   $ kubectl delete tektonpipelines.operator.tekton.dev pipeline

2. Verify Pipeline Instance Deletion

   $ kubectl get tektonpipelines.operator.tekton.dev pipeline

   Ensure the command returns no resources, indicating successful deletion.

3. Uninstall Tekton Operator

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

4. Verify Operator Uninstallation

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

   Ensure the command returns no results, indicating successful uninstallation.

#2. Deploy Alauda DevOps Pipelines

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

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:

   $ 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.

#3. (Optional) Adjust Operator Resources for Large-Scale Migrations

If your environment contains a large number of existing TaskRun and PipelineRun resources, the Tekton Operator may encounter Out of Memory (OOM) errors during the one-time data migration process. Since the operator doesn't normally require such extensive resources, the default resource limits may be insufficient.

#Adjusting Operator Resources

You can temporarily increase the operator's resource limits using either of these methods:

Method 1: Using the Platform UI

1. Navigate to the Alauda DevOps Pipelines operator page
2. Go to the Subscription tab
3. Click the Edit Subscription button
4. Add the resource configuration as shown below

Method 2: Using kubectl CLI

kubectl edit subscriptions.operators.coreos.com -n tekton-operator tektoncd-operator

Add the following config section under spec:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: tektoncd-operator
  namespace: tekton-operator
spec:
  channel: pipelines-4.0
  installPlanApproval: Manual
  name: tektoncd-operator
  source: platform
  sourceNamespace: cpaas-system
  config:
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "2"
        memory: "2Gi"

This configuration adjusts the tekton-operator Pod's resource quotas.

#4. Configure TektonConfig

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.

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

  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: {}

#5. (Optional) Monitor and Verify Migration Progress

After the Alauda DevOps Pipelines operator is deployed (step 2), it automatically begins migrating existing Tekton resources. You can monitor the migration progress and verify completion at any time during or after the configuration process.

#Method 1: Monitor Through Operator Logs

You can watch the migration progress in real-time by checking the tekton-operator-webhook logs:

kubectl logs -f -n tekton-operator tekton-operator-webhook-<suffix>

During the migration, you will see log entries like:

• migrating %d group resources - Indicates the total number of resource types to be migrated
• migrating group resource - Shows when migration of a specific resource type begins
• migration completed - Confirms that migration of a specific resource type has finished

#Method 2: Check TektonConfig Status

To verify that the migration is complete, check the TektonConfig resource status:

kubectl get tektonconfigs.operator.tekton.dev config -o yaml

Look for the version annotations in the output:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
status:
  annotations:
    operator.tekton.dev/post-upgrade-version: v0.74.1-a07f82b
    operator.tekton.dev/pre-upgrade-version: v0.74.1-a07f82b
  version: v0.74.1-a07f82b

Migration is complete when pre-upgrade-version and post-upgrade-version match the current version.

#6. Configure Log Access Permissions

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.

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 Alauda DevOps Tekton v3 to Alauda DevOps Pipelines. 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.