v1.9.0 Release Notes
Zadig v1.9.0 was released on January 27, 2022.
# Feature List
Data Analysis
- Data overview
- Performance insights
Workflow
- Workflow triggers support tag events
- Workflow adds extension for image version rollback functionality
- Workflow tasks support search and filtering by execution information and status
- Workflow IM notifications include detailed runtime information
- Workflow environment variables support choice parameter type
Others
- Testing supports IM notification functionality
- Custom image registry pull image policy changed to always
Bugfix
- Fixed workflow Webhook not being properly cleaned up
- Fixed managed projects unable to deploy when services with same name exist
- Fixed workflow list service deployment link navigation issue in managed projects
- Fixed delivery center - version release unable to select integration environment
# Version Upgrade Process
Warning
Supports upgrading from v1.7.0 and above to v1.9.0. If current system version < v1.7.0, please first upgrade to v1.7.0. For specific upgrade process, see v1.7.0 Upgrade Method, then follow the method below to upgrade to v1.9.0
# Database Backup
If already in production use, be sure to backup the database before upgrading
- Database backup commands:
- Backup MongoDB data
mongodump -h IP --port PORT -u USERNAME -p PASSWORD -d DATABASE -o FILE_PATH
- Backup MySQL data
mysqldump -h <HOST> -P <PORT> -u root -p user > user.sql
mysqldump -h <HOST> -P <PORT> -u root -p dex > dex.sql
2
- Database restore commands:
- Restore MongoDB data
mongorestore -h IP --port PORT -u USERNAME -p PASSWORD -d DATABASE --drop FILE_PATH
- Restore MySQL data
# Execute the following in MySQL:
mysql> drop database user;
mysql> create database user;
mysql> drop database dex;
mysql> create database dex;
# Execute the following data recovery operations from command line:
mysql -h <HOST> -P <PORT> -u root -p user < user.sql
mysql -h <HOST> -P <PORT> -u root -p dex < dex.sql
2
3
4
5
6
7
8
# Upgrade Operations
Please execute corresponding upgrade steps according to different installation methods.
# Installation Method: All in One Installation Mode or Installation on Existing Kubernetes
For both installation methods, use scripts from Installation on Existing KubernetesNew for upgrade, with the following considerations:
Warning
- Pay special attention to configuring ENCRYPTION_KEY, otherwise it will cause inability to access previous data after upgrade. For information on obtaining ENCRYPTION_KEY, refer to: How to get ENCRYPTION_KEY.
- If upgrading from v1.7.0/v1.7.1 to v1.9.0 and installed using IP + PORT method, please change the PORT parameter to specify a different port to avoid upgrade failure due to port occupation.
# Installation Method: Helm Command Installation
For this installation method, execute the following steps to upgrade to v1.9.0:
- Execute the following command and check the zadig.yaml file. If the file contains image information (i.e.,
tag:a.b.c), it needs to be manually deleted.
helm get values <Release Name> -n <Zadig Namespace> > zadig.yaml
- Execute upgrade command according to installation method.
- Domain method:
export NAMESPACE=<Zadig Installation NAMESPACE>
helm repo update
helm upgrade -f zadig.yaml <release_name> koderover-chart/zadig --namespace ${NAMESPACE} --version=1.9.0
2
3
4
- IP + PORT method:
Warning
If upgrading from v1.7.0/v1.7.1 to v1.9.0, please use a different port than when installing to upgrade v1.9.0 to avoid upgrade failure due to port occupation.
export NAMESPACE=<Zadig Installation NAMESPACE>
export PORT=<Any port between 30000-32767, different from initially used port>
helm repo update
helm upgrade -f zadig.yaml <release_name> koderover-chart/zadig --namespace ${NAMESPACE} \
--set gloo.gatewayProxies.gatewayProxy.service.httpNodePort=${PORT} \
--set gloo.gatewayProxies.gatewayProxy.service.type=NodePort --version=1.9.0
2
3
4
5
6
7
# (Optional) Post-Upgrade Operations
If upgrading from v1.7.0/v1.7.1 to v1.9.0 and external clusters were integrated in the Zadig system before upgrade, after upgrading to v1.9.0, you need to disconnect the external cluster connection and re-integrate it, otherwise the functionality of using that cluster for builds will be abnormal. For cluster integration, refer to: Cluster Management.


