Workflow Tasks

Workflows have capabilities such as building, deployment, verification, process control, release and rollback, project collaboration, configuration changes, data changes, gateway changes, service monitoring, CI/CD integration, and general tools. 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

# Container Service Deployment

Parameter Description:

• Task Name: Supports lowercase English letters, numbers, or hyphens within 32 characters, and must start with a lowercase English letter; task names must be unique within the same workflow

• Environment: Select the environment to deploy to. Refer to Variable Assignment

• Service Component: Supports manual input or specifying a preceding build task (the system uses 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 service variables. For variable definitions, refer to Service Variables
    • Variable sources support runtime input and global variables/other task outputs
  • Service Configuration: Update the service configuration. For the service configuration source, refer to Service Configuration

• Service Variables and Configuration: When Deployment Content includes Service Variables, configure the services and variables that the workflow can update

• Deployment Strategy:

  • K8s YAML Service:
    • Merge: Only apply changes to fields managed by Zadig, while preserving changes to other fields in the namespace. For example, when the workflow updates env and replicas in the service YAML, manually adjusted resources and labels in the cluster are preserved.
    • Overwrite: Fully replace the existing configuration in the namespace with Zadig YAML; all differences in the same resource will be overwritten. For example, when the same env and replicas updates are applied, manually adjusted resources and labels in the cluster are also replaced with the values in the service YAML.
  • K8s Helm Chart Service: For example, the current environment values include replicaCount, env, ingress, and service.type, and this workflow run only passes in replicaCount and env:
    • Merge: Merge with the current environment variables, equivalent to Helm CLI --reuse-values. Fields not passed in (ingress and service.type) keep their current environment values.
    • Overwrite: Use the input variables to overwrite the current values. Fields not passed in (ingress and service.type) fall back to the Chart defaults.

• Configuration Sync Policy:

  • Manual Import: During execution, you can manually import the latest configuration from code and allow modifications
  • Auto Sync: During execution, the latest configuration from the code repository is used mandatorily and modifications are not allowed

• Status Detection: If enabled, the deployment task polls the service running 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 is exceeded without meeting the success/failure conditions, the deployment times out. The deployment timeout setting can be found in Service Policy Configuration

# Container Service 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

# Host Service Deployment

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)

# K8s Service 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 K8s Service 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 task status will be successful only if the container runs normally before the deployment timeout
• Timeout: Container deployment timeout

# K8s YAML Update

It can help solve the problem of automatically updating native K8s resources, such as updating container CPU 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
  • 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.

# Service Offline

Supported in K8s YAML projects and K8s Helm Chart projects.

Remove the service from the environment.

# Verification

# 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 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 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 repository in code scanning, enable shared storage as needed, and refer to Shared Storage for configuration.

# Test Execution

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 Use the code information of the selected task. 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:

• Variable Assignment
• Shared Storage

# Process Control

# Manual Approval

Supports Zadig Approval, Feishu Approval, DingTalk Approval, and Enterprise WeChat Approval. For detailed configuration and usage, refer to Workflow Approval.

# Send 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 and Rollback

Supports blue-green release, canary release, grayscale release, Istio release, MSE grayscale release, Helm Chart deployment, and other capabilities. For details, refer to Release Strategies.

# Istio Grayscale Policy Update

Automatically update the grayscale policy in Istio full-link grayscale. For usage practice, refer to Istio Full-Link Grayscale.

• Task Name: In the same workflow, the task name must be unique.
• Baseline Environment: Baseline production environment
• Grayscale 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

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

# Agent

# AI Release Specialist

Perform AI risk analysis based on change and release context, and output conclusions and recommendations.

Parameter Description:

• Task Name: In the same workflow, the task name must be unique.
• Timeout: Task execution timeout.
• Detection Items and Evidence Template: Enter detection items and evidence template. Supports detecting task status in the workflow, test and code scan reports, runtime environment service status, monitoring alerts, and more.
• Agent Output Spec: Built-in output specification; not customizable.
• Manual Confirmation: When enabled, the task waits for manual confirmation after the release specialist completes analysis, then continues.

When the workflow runs, the release specialist performs release detection based on the release context and outputs conclusions and recommendations.

# AI Task

Connect to a custom Agent or AI model and automatically execute intelligent tasks based on the prompt.

Parameter Description:

• Task Name: In the same workflow, the task name must be unique.
• Target: An agent registered in Zadig, see Agent Project, or an AI model, see AI Models.
• Prompt: Enter the prompt.
• Manual Confirmation: When enabled, the task waits for manual confirmation after the agent completes execution, then continues.
• Timeout: Task execution timeout.

When the workflow runs, the AI Task automatically executes the intelligent task based on the prompt and outputs the result.

# Project Collaboration

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

# 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 issue to be changed. Refer to Variable Assignment.
• Target Status: Select the status you need to change to.

# 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

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

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

# Data Changes

# SQL Change Execution

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 Ticket Execution

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
• Execution Mode: Parallel or serial. If serial is selected, the next DMS work order will be executed only after the current DMS work order finishes.
• 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 Service 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 occur, you can click to view the event details to analyze whether the service is healthy.

# CI/CD Integration

# Jenkins Job Execution

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

# BlueKing Job Execution

Can trigger the execution plan of the BlueKing Job Platform.

Parameter Description:

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

# General Tools

# General Script Execution

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 Build Environment Configuration
• Code Information: Configure the code repository for the general script execution task, supporting two methods: direct configuration and variable assignment
  • Direct configuration: For specific fields, refer to Code Information
  • Use variables: After configuring the workflow variable of the code repository type, set the value of the code source here to Global Variables/Other Task Outputs. For configuring workflow variables, refer to Custom Variables
• Variables: Configure custom variables for general script execution tasks. Variable assignment supports three ways. Refer to Variable Assignment
• Add Steps: Including adding Shell script execution and file storage. Refer to More Build Steps
• Advanced Configuration: Refer to Advanced Configuration
  • 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 Output Variables.

# Workflow Trigger

Can trigger other workflows.

• The triggered workflow needs to meet the criteria: only General Script Execution/Custom Tasks/Workflow Trigger tasks
• Can trigger workflows in all projects

Supports triggering all configured 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, refer to Custom Variables.

# 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:

• Timeout Policy Configuration
• Resource Configuration
• How to Use Shared Storage