Upgrade Alauda DevOps Pipelines Operator
This document provides instructions for upgrading the Alauda DevOps Pipelines Operator to a newer version using the Marketplace/OperatorHub interface in your cluster. The upgrade process is designed to be straightforward while ensuring minimal disruption to existing Tekton resources.
TOC
Upgrade OverviewBefore You BeginConfirm Target Channel FirstUpgrade ProcessUsingMarketplace/OperatorHubUsing kubectl CLIPost-Upgrade StepsVerify migrated TektonHub custom catalogsRollback ProcedureTroubleshootingNext StepsUpgrade Overview
Upgrading the Alauda DevOps Pipelines Operator allows you to access new features, bug fixes, and improvements to the Tekton ecosystem. The Alauda DevOps Pipelines Operator handles the upgrade of all Tekton components (Pipelines, Triggers, Hub, etc.) according to your configuration.
Before You Begin
Before upgrading the Alauda DevOps Pipelines Operator, ensure you:
- Have administrative access to your cluster
- Review the release notes for the new version to understand any breaking changes
- Verify that your existing Tekton component configurations are compatible with the new version
- Confirm that all Tekton components are in a ready state
- Upload a new version of the Operator, refer to the installation guide for operator upload instructions .
Starting from v4.12.0, the built-in Tekton Hub is no longer deployed by default, and upgrading to v4.12.0 or later removes an existing built-in Tekton Hub deployment. Starting from v4.14.0, the built-in Tekton Hub runtime is no longer shipped at all: the operator carries no Tekton Hub manifests and the AUTOINSTALL_TEKTONHUB switch is gone, so it cannot be re-enabled after the upgrade. Migrate catalog publishing and consumption to ArtifactHub Shim before upgrading. For catalog details, see ArtifactHub Shim Catalog.
Starting from v4.14.0, legacy TektonHub custom catalog settings are automatically migrated to ArtifactHub Shim before the old Tekton Hub runtime is cleaned up. The operator reads TektonHub.spec.catalogs[] and the old tekton-hub-api ConfigMap CATALOGS data, then creates artifacthub-shim-legacy-tekton-hub-catalogs in the ArtifactHub Shim namespace. The migration does not fetch TektonHub.spec.api.hubConfigUrl. For details about migrated repository configuration, see Configure Custom Git Repositories.
Confirm Target Channel First
Before you approve an upgrade, confirm which channel your Subscription uses:
stable(default): Tracks LTS releases only, recommended for production.latest: Tracks all releases, including non-LTS.pipelines-4.14: Tracks patch updates in thev4.14LTS line only. Apipelines-x.ychannel exists for every LTS version, sopipelines-4.10still tracks the previous LTS line.
If you are currently on a non-LTS version in latest, switching to stable does not downgrade. You might stay on the current version without a new upgrade prompt until a newer LTS is published.
Upgrade Process
Using Marketplace/OperatorHub
-
Access the
Marketplace/OperatorHub- Log in to your cluster's management console
- Navigate to the
MarketplaceorOperatorHubsection
-
Locate the
Alauda DevOps PipelinesOperator- Search for
Alauda DevOps Pipelinesin the search bar - Click on the
Alauda DevOps Pipelinescard
- Search for
-
View Available Versions
- On the
Alauda DevOps PipelinesOperator details page, you'll see information about the currently installed version - The interface will indicate if a newer version is available
- You can click different
Channelsto view all available versions
- On the
-
Initiate the Upgrade
- If the target version is in a different
Channel, switch to the correspondingChannelin theSubscriptionfirst - If the current
Channelhas a newer version available, you will see a prompt:- New Version Detected
- To upgrade only the current Operator, click
Confirmto upgrade.
- To upgrade only the current Operator, click
- New Version Detected
- If the target version is in a different
-
Configure Upgrade Settings (if applicable)
- Some upgrades may present configuration options
- In most cases, the default settings will preserve your existing configuration
-
Confirm and Start the Upgrade
- Click
Confirmto begin the process - Review the upgrade details and confirm your selection
- The system will update the
Alauda DevOps PipelinesOperator while maintaining your custom resources
- Click
-
Monitor the Upgrade
- The upgrade progress will be displayed in the
OperatorHubinterface - You can also check the status in the
tekton-operatornamespace: When all pods are inRunningstate, the operator upgrade is complete. The operator will then automatically upgrade components such asPipelines,Triggers,Chains, etc. (andHub, if you have enabled the built-inTekton Hub). - Check the components upgrade status:
When all components and pods are in
Readystate, the components upgrade is complete.
- The upgrade progress will be displayed in the
-
Verify the Upgrade
- Check that the
Alauda DevOps PipelinesOperator version has been updated: When theVERSIONmatches the new version, the upgrade is complete. - Verify that your Tekton components are functioning correctly
- Test that your pipelines can run successfully
- Check that the
Using kubectl CLI
You can also upgrade the Alauda DevOps Pipelines Operator using the command line interface. This method is useful for automation or when you prefer CLI-based operations.
-
Check Current Subscription
- First, identify the current subscription and its channel:
-
Switch to Target Channel
- If you need to upgrade to a version in a different channel, patch the subscription:
Replace
<target-channel>with the desired channel (e.g.,stable,latest,pipelines-4.14).
- If you need to upgrade to a version in a different channel, patch the subscription:
Replace
-
Wait for UpgradePending State
- Monitor the subscription status until it shows
UpgradePending: Look for thestate: UpgradePendingin the output.
- Monitor the subscription status until it shows
-
Approve the InstallPlan
-
When the subscription is in
UpgradePendingstate, find the corresponding InstallPlan: -
Approve the InstallPlan by setting the
approvedfield totrue:Replace
<installplan-name>with the actual InstallPlan name from the previous step.
-
-
Monitor the Upgrade Progress
-
Watch the subscription status until it becomes ready:
-
Check the operator pods status:
Wait until all pods are in
Runningstate.
-
-
Verify the Upgrade
- Confirm the operator version has been updated:
-
Monitor Component Upgrades
- The operator will automatically upgrade Tekton components. Monitor their progress:
Ensure all components and pods reach
Readystate.
- The operator will automatically upgrade Tekton components. Monitor their progress:
Ensure all components and pods reach
The CLI upgrade process follows the same underlying mechanism as the GUI method. The main difference is that you manually control the channel switching and InstallPlan approval steps.
Post-Upgrade Steps
After the upgrade completes successfully:
-
Verify Component Status
- Check that all Tekton components have been updated:
-
Test Functionality
- Run a simple pipeline to verify that the system is working correctly
- Ensure that all existing integrations continue to function
-
Update Custom Resources if Needed
- If the new version introduces changes to CRDs, you may need to update your custom resources
- Refer to the release notes for specific migration steps
Verify migrated TektonHub custom catalogs
If the cluster had TektonHub.spec.catalogs[] or custom CATALOGS data in the old tekton-hub-api ConfigMap, verify that the generated ArtifactHub Shim repository ConfigMap exists:
If ArtifactHub Shim is installed in a different namespace, use the namespace in TektonConfig.spec.pipeline.hub-resolver-config.artifact-hub-api. For the repository ConfigMap format and credential options, see Configure Custom Git Repositories.
Generated entries use this naming pattern:
The generated entries set optional: true. Pipeline and StepAction entries set legacyCatalogAliases: ["<catalog>"], so old hub resolver references can keep using the original catalog name while new references should use the generated canonical repository names.
If the legacy SSH Secret existed, verify the copied Secret:
The copied Secret is normalized for ArtifactHub Shim and contains sshPrivateKey plus known_hosts. If the legacy Secret does not include known_hosts, has no private key, or has multiple private key candidates such as both id_rsa and id_ed25519, the operator leaves the migrated SSH catalog without credentialRef. The ArtifactHub Shim source will then report the Git credential problem during refresh.
The operator skips entries that conflict with existing ArtifactHub Shim repositories or aliases, and it does not overwrite a same-name ConfigMap or Secret that was not generated by this migration. Review the operator logs if an expected migrated catalog is missing.
Rollback Procedure
If you encounter issues with the new version, you can roll back to the previous version:
- Return to the
Marketplace/OperatorHubinterface - Select the
Alauda DevOps PipelinesOperator Uninstallthe current version- Choose the previous version from the version list
- Follow the installation process for that version
Downgrading may require additional steps to ensure compatibility of your resources with the older version.
This depends on the differences between the version you upgraded from and the version you upgraded to. If the differences are large, you may need to manually migrate resources.
Troubleshooting
If you encounter issues during or after the upgrade:
-
Check the
Alauda DevOps PipelinesOperator pod logs: -
Verify the status of your Tekton resources:
-
Ensure that all components have the expected status:
Next Steps
After successfully upgrading the Alauda DevOps Pipelines Operator:
- Explore new features introduced in the latest version
- Update your CI/CD pipelines to leverage new capabilities
- Consider enabling additional components that may be available in the new version