Workflow Tasks

Workflows have capabilities such as building, deploying, testing, production releases, project collaboration, configuration changes, data changes, and service monitoring. This article introduces how to configure and use the tasks corresponding to these capabilities.

# Build

# Build

Parameter Description:

• Task Name : Supports lowercase English letters, numbers, or hyphens within 32 characters, and must start with a lowercase English letter; in the same workflow, the task name must be unique
• Image Repository : Select the image repository. After the build task is successfully executed, the built image (i.e., the built-in $IMAGE variable) will be pushed to the selected repository
• Service Component : Supports runtime input or specifying pre-tasks.
• Component List :
  • Variable Configuration : Configure the variable value in the build, see variable assignment
  • Branch Configuration : Select the code repository and specify the default branch and branch options. The specified branch will be used by default when executing the workflow
  • Shared Storage Configuration : See shared storage

# Deployment

# Deploy

Parameter Description:

• Task Name : Supports lowercase English letters, numbers, or hyphens within 32 characters, and must start with a lowercase English letter; in the same workflow, the task name must be unique
• Environment : Select the environment to be deployed, and see variable assignment
• Service Component : Supports two configuration methods: manual input or specifying pre-build tasks (the system will use the $IMAGE variable output from the build task to deploy the service)
• Deployment Content : Includes the following three options:
  • Service Image : Update the service image
  • Service Variables : Update the service variables. See the definition of variables: Service variables
    • Variable sources support runtime input and global variables/other task outputs
  • Service Configuration : Update the service configuration. See the service configuration source: Service Configuration
• Service Variables and Configuration : When Deployment Content includes Service Variables, configure the services and variables that can be updated by the workflow
• Status Detection : If enabled, the deployment task will poll the service operation status
  • If the service instance's Replicas = AvailableReplicas, the deployment is successful, and the workflow task status is successful
  • If the service container is in a waiting state due to ImagePullBackOff/ErrImagePull/CrashLoopBackOff/ErrImageNeverPull, it is considered a deployment failure, and the workflow task status is a failure
  • When the deployment timeout time is exceeded, the success is not met / Failure condition, the deployment timeout is exceeded. The deployment timeout setting can see service policy configuration

# Restart

Parameter Description:

• Task Name : Supports lowercase English letters, numbers, or hyphens within 32 characters, and must start with a lowercase English letter; in the same workflow, the task name must be unique
• Environment : The environment to be restarted
• Service Name : Supports two configuration methods: runtime input and other task outputs

# Deploy to Host

Parameter Description:

• Task Name : Supports lowercase English letters, numbers, or hyphens within 32 characters, and must start with a lowercase English letter; in the same workflow, the task name must be unique
• Environment : The environment to be deployed
• Object Storage : Object storage for binary package storage
• Service Component : Supports two configuration methods: runtime input and other tasks (the system will use the $IMAGE and $ARTIFACT variables output from the build task to deploy the service)

# Kubernetes Deployment

Deploy containers in the specified namespace of the specified cluster.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique
• Image Repository : When executing the Kubernetes deployment task, which image repository is used to retrieve the image to deploy the target container
• Cluster : The cluster where the container to be deployed is located
• Namespace : The namespace where the container to be deployed is located
• Container : Specify container applications in the namespace (currently supports Deployment resources and Statefulset resources)
• Container Status Detection : If enabled, the deployment task will poll the container's running status. The container runs normally before the deployment timeout, and the task status will be successful
• Timeout : Container deployment timeout

# Update K8s YAML Task

It can help solve the problem of automatically updating native K8s resources, such as updating container CPUs and Mem, updating Istio's VirtualService configuration, etc.

Parameter Description:

• Cluster : Cluster information
• Namespace : The namespace where the instance is located in K8s
• Resource Name : The resource name that needs to be modified, supports updating multiple resources at once
• Update Content :
  • Template : Configure the corresponding update content, supports variables in {{.Key}} format. After setting variables in the template, the variable area will be automatically parsed, and variable types and default values can be configured. The parsed variables can be used
  • Strategy : Supports strategic-merge/merge/json. See the K8s official documentation(opens new window) for specific usage methods

Execute the workflow, fill in the variables for the updated content, and the workflow completes execution according to the set tasks.

# Test

# Test

Supports referencing test configurations in workflows.

Task types include service testing and product testing:

• Product Test : Just specify the test
• Service Test : Specify the service component and configure the corresponding relationship between the service component and test. The source of the service component can be specified as runtime input or as pre-task output (including: build tasks, deployment tasks, image distribution tasks)
  • Service Component : Supports two configuration methods: runtime input and pre-build task. If there is code information in the pre-task, you can choose Repo Sync. If the code repository of the test task is consistent with the selected task, then when executing the workflow, you only need to select service components and code information in the pre-task, and the test task will automatically reference the corresponding input.

After selecting the specific test configuration, you can set the default branches and variables of the code repository in the test configuration, and enable shared storage as needed. Refer to the document:

• Variable assignment
• Shared storage

# Code scanning

Use the configured Sonar for code scanning tasks to verify code quality.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Task Type :
  • Product Scan : Just scan the specified code.
  • Service Scan : Specify the service component and configure the corresponding code scanning task for scanning. The selection of the service component supports output from the pre-task, and can be chained with build tasks.
    • Service Component : Supports two configuration methods: runtime input and pre-build task. If there is code information in the pre-task, you can choose Repo Sync. If the code repository of the code scanning task is consistent with the selected task, then when executing the workflow, you only need to select service components and code information in the pre-task, and the code scanning task will automatically reference the corresponding input.
• Scan Name : Select the code scanning task in the project, and you can choose multiple options.
• Scan Configuration : You can set the default branch of the code base in code scanning, enable shared storage as needed, and you can refer to shared storage for configuration.

# Process Control

# Manual Approval

Support Zadig Approval, Feishu Approval, DingTalk Approval, Enterprise WeChat Approval, detailed configuration and use of reference documents workflow Approval

# Notification

During the execution process, the workflow supports orchestrating notification tasks. Notification members support runtime input or fixed members. Currently, it supports four notification methods: email, Enterprise WeChat, Feishu, and DingTalk.

# Release Strategies

Supports Helm Chart Deployment, MSE, Blue-Green Deployment, Canary Deployment, Batched Gray Deployment, and Istio Deployment. For detailed information, refer to the document: Publishing Policy.

# Helm Chart Deployment

Applicable only in K8s Helm Chart projects.

Charts that are already in the Chart repository can be automatically deployed to the environment.

# Configure Tasks

Edit the workflow and add the "Helm Chart Deployment" task: Click "+ Task", select the "Helm Chart Deployment" task, and configure the environment.

# Perform Tasks

Select the environment, Release, and modify the Chart information and values content as needed, then execute the workflow.

# Update Istio Gray Policy

Automatically update the Istio gray policy in the full link gray. For usage practice, refer to Istio Full Link Gray.

• Task Name : In the same workflow, the task name must be unique.
• Baseline Environment : Baseline production environment
• Gray Strategy :
  • Based on Traffic Ratio : Control production traffic according to the configured traffic ratio
  • Based on Request Header : Control production traffic according to the configured request header

# Project Management

# JIRA Issue Status Change

After completing a certain stage of the workflow, the status of the Issue in the corresponding JIRA project can be automatically changed.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Jira Project : Select the corresponding project under the Jira space.
• Issue Type : Select the corresponding type as needed.
• JQL Search: In Advanced Search, it supports searching for issues using JQL statements. Ensure the correctness of the JQL statement.
• Change Issue : Select the problem of the required change and refer to the document variable assignment .
• Target Status : Select the status you need to change to.

# Feishu Work Item Status Change

After completing a certain stage of the workflow, the status of the work item in the corresponding Feishu space can be automatically changed.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Space : Select the desired Feishu space.
• Work Item Type : Select the corresponding type as needed.

When executing the workflow, select the work item to be changed and the corresponding target status. After clicking to execute, the Feishu project status will be automatically changed.

# PingCode Work Item Status Change

After completing a certain stage of the workflow, the status of the work item in the corresponding PingCode project can be automatically changed.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Access Address : Select the bound PingCode access address.
• Project : Select the corresponding project under the PingCode space.
• Kanban : Select the kanban under the project for filtering work items.
• Work Item Type : Select the corresponding type as needed for filtering work items.
• Current Status : Select the current status of the work item to be changed for filtering work items.

When executing the workflow, select the work item to be changed and the corresponding target status. After clicking to execute, the PingCode work item status will be automatically changed.

# Tapd Work Item Status Change

After completing a certain stage of the workflow, the status of the work item in the corresponding Tapd project can be automatically changed.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Access Address : Select the bound Tapd access address.
• Project : Select the corresponding project under the Tapd space.
• Type : Currently only supports iteration.
• Target Status : Iteration change target status, currently only supports closing.

When executing the workflow, select the work item to be changed. After clicking to execute, the Tapd work item status will be automatically changed.

# Configuration changes

# Apollo Configuration Change

Through the execution of workflow tasks, multiple configuration changes managed by Apollo can be supported simultaneously.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Apollo Address : Select the bound Apollo address. If you need to add one, go to Apollo Configuration to view details.
• Apollo Configuration Range: Configure the configuration scope that can be changed. When disabled, all configurations in Apollo are listed. Supports TEXT, JSON, XML, YAML, HTML, Properties, and other formats. Namespace supports selecting "All", and when executing the workflow, all namespaces under the selected cluster will be listed.

# Nacos Configuration Change

Through the execution of workflow tasks, multiple configurations managed by Nacos can be changed simultaneously. After execution, the workflow supports rolling back the Nacos configuration to the version before the change.

Parameter Description:

• Task Name: In the same workflow, the task name must be unique.
• Nacos Address: Select a previously bound Nacos address. If you need to add one, go to Nacos Configuration for more details.
• Namespace: Select the desired namespace.
• Group: Select a group to filter configurations.
• Configuration: Select the corresponding configuration, and multiple selections are supported.

# Data changes

# SQL Data Changes

SQL commands can be executed for the specified database, combined with build and other tasks, to achieve one-stop data and code changes. SQL data rollback is supported, and the rollback SQL scripts must be provided by the user.

Parameter Description:

• Database : Select the database to be changed, which must be integrated into the system in advance
• SQL Statement : The SQL statement for the change, supporting multiple lines. Please specify the database name in the SQL statement

# DMS Data Change Work Order

Select an existing work order on DMS for execution and wait for the execution result.

Parameter Description:

• Service Connection: Select the DMS data management service configured in the system integration
• Comment Template: Configure a comment template to prompt the executor to fill in the comment content

# Gateway Changes

# APISIX Gateway Changes

Update the configuration of the specified APISIX gateway.

Parameter Description:

• APISIX Address : Select the APISIX address configured in the system integration

When executing the workflow, select the APISIX gateway to be changed and the corresponding target configuration. After clicking to execute, the APISIX gateway configuration will be automatically changed.

# Service Monitoring

# Grafana Monitoring

Use Grafana to monitor the service health during the specified monitoring period.

Parameter Description:

• Grafana Service : Select the Grafana monitoring system configured in the system integration
• Monitoring Time : Configure the Grafana monitoring time
• Select Alert Rules : Select the alert rules configured in the Grafana system
• Failure Strategy : Configure the failure strategy for the workflow task, including the following two options:
  • Single Monitor Abnormal Task Immediately Failed : If any monitor result is abnormal, the workflow task will fail immediately and will not wait for all monitors to complete
  • All Monitors Completed with Abnormal Results : The workflow task will fail if there are any abnormal results after all monitors have completed

When monitoring abnormalities, you can click to view the event details to analyze whether the service is healthy.

# CI/CD

# Execute Jenkins Job

Supports executing multiple Jenkins jobs using the workflow.
Specific configuration method: Add an Execute Jenkins Job task to the workflow -> Select the Jenkins system -> Add multiple Jenkins jobs -> Configure the parameters in the Jenkins job.

# Execute Blue Whale Operation

Can trigger the execution plan of the Blue Whale Operation Platform.

Parameter Description:

• Blue King System : Select the Blue Whale system configured in the system integration
• Business : The business unit in Blue Whale
• Execution Plan : Select a predefined execution plan in the Blue Whale system

# Other Requirements

# General Tasks

Supports functions such as pulling code, executing shell scripts, and file storage.

• Execution Method :
  • Single Task Execution : Execute only one task
  • Service Component Multi-Task Execution : Divide into multiple tasks based on the selected service component
    • Service Component : Supports two configuration methods: runtime input and pre-build tasks. If there is code information in the pre-task, you can choose Use the code information of the selected task. If the code repository of the code scanning task is consistent with the selected task, then when executing the workflow, you only need to select the service component and code information in the pre-task, and the code scanning task will automatically reference the corresponding input.
• Execution Environment : Refer to the build environment configuration
• Code Information : Configure the code repository for the general task, supporting two methods: direct configuration and variable assignment
  • Direct configuration: For specific fields, please refer to the document code information.
  • Use variables: After configuring the workflow variable of the code base type, set the value of the code source here to Global Variables/Other Task Output You can refer to the variable for configuring the workflow variable.
• Variables : Configure custom variables for general tasks. Variable assignment supports three ways, refer to variable assignment
• Add Steps : Including adding Shell script execution and file storage, please refer to more build configurations
  • Among them, the Select Cluster configuration source supports runtime input and fixed values.

# Image Distribution

Images can be pushed to a specified image registry.

Parameter Description:

• Task Name : In the same workflow, the task name must be unique.
• Service Component : The service component that needs image distribution, supporting manual input and other task outputs.
• Source image registry : The source of the image to be distributed.
• Target image registry : The target repository for image distribution.
• Distribution Method :
  • Image Push : Retag the image and push it to the target image registry
  • Modify Address Only Without Push : Only modify the image address without pushing to the target image registry. You can use cloud vendor multi-region synchronization. Zadig is only responsible for converting the image address to ensure that subsequent tasks can obtain the correct image address, while the actual image synchronization is completed by the cloud vendor.
• Image Version Rule : Turn on and configure the rules. The image distribution task will generate the version of the target image according to the specified rules, supporting the following combinations of variables and constants.

When executing the image distribution task, the image versions of all services are generated according to the rules in the configuration.

In addition to the above variables, it also supports the use of variables output in the pre-task. Refer to the document: Output variables .

# Trigger Zadig Workflow

Can trigger other Zadig workflows.

• The triggered workflow needs to meet the criteria: only common tasks/custom tasks/triggered Zadig workflow tasks
• Can trigger workflows in all projects

Supports triggering all workflows or specifying the corresponding relationship between service components and workflows to trigger partial workflows.

Click Variable Configuration to configure custom variables in the triggered workflow to realize variable transmission across workflows and projects. For workflow custom variables, please refer to the documentation: Custom variables .

# Offline Service

Supported in K8s YAML projects and K8s Helm Chart projects.

Remove the service from the environment.

# Custom Tasks

Define the implementation of tasks yourself and configure custom tasks in the workflow. For detailed usage, refer to Custom Tasks.

# Supported Configuration Methods in Different Tasks

The related configuration items in the task support rich assignment methods . See the following table for the supported methods in different tasks:

# Advanced Configuration

In the advanced configuration of the task, you can specify the task's timeout time, the cluster resources used, the scheduling policy, and whether to enable shared storage, etc. The list of tasks that support advanced configuration is as follows:

For timeout time, resource configuration, and shared storage configuration, refer to the documentation:

• Timeout policy configuration
• Resource configuration
• How to use shared storage