Build Configuration

Zadig build supports operations such as pulling code, compiling code, building Docker images/APK packages/Tar packages, pushing images, and uploading to object storage. It comes with common build environments and software packages and supports build caching.

• Supports configuring multiple builds for a service, and select on demand in the workflow configuration. For more details, please refer to Workflow - Build task configuration
• It supports multiple services using the same build configuration. For more details, please refer to Shared Build
• Supports modifying the generation rules for building deliverables. For more details, please refer to Build deliverable generation rules

# Basic Configuration

Parameter Description:

• Build Name: Customize it to be meaningful and easy to understand
• Service Selection: Select the service to use this build configuration

# Build Environment

Configure the environment for the build process, supporting both Kubernetes and host infrastructure.

# Using Kubernetes

The build process runs in a K8s Pod, and you can configure operating system and software package dependencies.

• Operating System: The platform provides by default Ubuntu 18.04 / Ubuntu 20.04 as the basic build system, it supports adding custom images as the build operating system, refer to Build image management
• Dependencies Software Package: Various software package tools needed during the build process, such as different versions of Java, Go, Govendor, Node, Bower, Yarn, Phantomjs, etc.

# Using Host

Execute build steps on the selected host, and the required software, tools, etc., can be installed in advance on the host.

# Code Information

Parameter Description:

• Code Source: The platform where the code base is located. Please refer to Code Source Information for supported code sources
• Code Repository Owner: Supports configuring all code repository owners under integrated code sources
• Code Repository Name: The name of the code repository
• Default Branch: The default branch selected when executing workflow configuration build variables, which can be modified during execution
• Remote name: Specifies the name of the remote code repository, default origin
• Clone Directory Name: Defines the directory name after the code repository is cloned, defaulting to the name of the code repository
• Submodule: Synchronizes the code repositories configured in submodule
• Pull Specific Commit: When enabled, supports selecting a specific Commit to execute when running the workflow
• Display when executing: On by default. If set to off, the code repository option will not be displayed when executing the workflow, and the code configuration will use the default value

The working directory structure is as follows:

├── $WORKSPACE         # The root directory of the build task
    ├── repository 1   # The first code repository
    ├── repository 2   # The second code repository
       ├── code       # The code in the second code repository
       └── ...
    └── ...

Where:

• $WORKSPACE is the built-in variable of the Zadig system build module, for a more detailed description, refer to System built-in environment variables

# Build Variables

Includes both system-built-in build variables and user-defined build variables, which can be used directly in the build script.

Tip: Add env commands to Build script to view all build variables.

Built-in Build Variables

Built-in variables and their descriptions are as follows:

Custom Build Variables

Explanation:

• Supports string (single-line/multi-line), single-choice, multiple-choice, file, and dynamic variable types
• You can set string-type variables as sensitive information, and the value of sensitive variables will not be output in the build log of the workflow task
• When executing workflow tasks, you can modify the values of custom build variables to override the default values configured here, as shown in the figure below:

# Build Script

Declare the build process and implementation in the build script.

Build variables can be used in build scripts

# Advanced Configuration

Explanation:

• Policy Configuration: Configure the timeout time for the build service. If the build is not successful after the set time threshold, it will be considered a timeout failure
• Cache Configuration: After caching is enabled, the cache directory configured here will be used when the workflow is executed. The directory configuration can use Build variables
• Cluster Selection: Select the cluster resource to be used when the build task runs, where the local cluster refers to the cluster where the Zadig system is located. For cluster integration, refer to Cluster Management
• Operating System Specification: Configure resource specifications for performing build tasks. The platform provides four configurations for High/Medium/Low/Lowest. In addition, you can also customize according to actual needs. If you need to use GPU resource, resource configuration form is vendorname.com/gpu:num, please refer to Scheduling GPU(opens new window) for more information
• Scheduling Policy: Select the cluster scheduling policy, and the default is Random Scheduling policy. Please refer to Set scheduling policy management
• Mount Storage: Mount persistent storage for build tasks, supports configuring storage type, storage size and mount path, can be used for storing build artifacts and other scenarios
• Use Host Docker daemon: After enabling, the Docker daemon on the node where the container is located will be used during the build execution process to perform Docker operations
• Privileged: After enabling, the container in the Pod will run in privileged mode. This is suitable for build scenarios that require running Docker inside the container or need higher system permissions. Note: Privileged mode has certain security risks and is only recommended in trusted environments
• Task Labels: Configure the Pod resource tags for the build task execution
• Task Annotations: Configure the Pod resource annotations for the build task execution
• Output Variables: Output the environment variables in the build, which can realize the variable transfer between different tasks in the workflow, refer to Variable passing

# More Build Steps

In Add Steps, you can add more build steps as needed.

Image Building

Build the image according to the configured parameters, using the built-in variable IMAGE as the name of the built image, and push it to the image repository.

Parameter Description:

• Build Context Directory: The directory where the execution docker build is located
• Dockerfile Source: Includes Code Repository and Template Library. For more information on the template library, see Dockerfile Template Management
• Dockerfile Absolute Path: When Dockerfile originates from the code base, specify the Dockerfile path used to execute docker build
• Template Selection: When the Dockerfile originates from the template library, select the specific Dockerfile template
• Build Parameters: All parameters that support docker build, such as: --build-arg key1=value1 --build-arg key2=value2
• BuildKit Build: After enabling, supports multi-platform builds, improving build efficiency and compatibility.

Among the above parameters, except Dockerfile Source and Template Selection, Variables can be used for all other parameters.

Binary Package Storage

Configure the storage path for the built binary package.

File Storage

Upload the specified file to the object storage. After uploading, the file will be stored in the specified directory of the corresponding bucket in the object storage. The directory here can use Variables, but it does not support nested variables, such as ${$REPO_0}_BRANCH.

• Upload specified file: configure the specified file path, such as infra/result.xml in the figure above
• Upload all files in the directory (excluding subdirectories): configure the specified directory, such as infra/examples/ in the figure above

Shell Script Execution

Add a Shell script execution step to perform certain operations after the build.