Help Center/ CodeArts Build/ User Guide/ Creating a Build Task/ Defining a Build Task with Code/ Creating the build.xml File for Multiple Tasks
Updated on 2025-06-09 GMT+08:00
View PDF

Creating the build.xml File for Multiple Tasks

A build task is the smallest unit that a build project can be broken down into for simple service scenarios. However, for more complex requirements, you may need to:

  • Use a multi-repo approach to distribute build tasks that depend on each other across multiple machines.
  • Set up multiple build tasks in a modular and fine-grained way, and run them in a specific order. Each task depends on the successful completion of its dependency task.

To handle such complex builds, CodeArts Build offers a task model called BuildFlow, which organizes multiple build tasks in a directed acyclic graph (DAG) and runs them in parallel based on their dependencies.

The following is a YAML file example for multiple tasks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
version: 2.0 # The version number is a mandatory and unique parameter that must be set to 2.0.
params: # Parameters that can be referenced by builds.
  - name: p
    value: 1
# env and envs are optional. Use envs if you need to specify conditions to determine the host specification and type.
env: # This parameter takes precedence once being set. The host specification and type defined here will be used instead of the ones set in the build environment configuration.
  resource:
    type:docker # Agent pool type. The value can be docker or custom. docker indicates that the default executor is used, and custom indicates that a custom executor is used.
    arch:X86 # The host type of the build environment can be either x86 or Arm.
    class:8 vCPUs | 16 GB # The specification can be: 2 vCPUs | 8 GB, 4 vCPUs | 8 GB, 8 vCPUs | 16 GB, 16 vCPUs | 32 GB, or 16 vCPUs | 64 GB. This parameter is not required when the agent pool type is set to a custom one.
    pool:Mydocker #Agent pool name. This parameter is required when the agent pool type is set to a custom one.
envs: 
    - condition: p == 1 # The following host specification and type are used if this condition is met.
      resource:
        type: docker 
        arch: ARM
    - condition: p == 0 # The following host specification and type are not used if this condition is not met.
      resource:
        type: docker
        arch: X86
# Configure either buildflow or buildflows. Use buildflows if you need to specify conditions to control job executions.
buildflow:
 strategy: lazy # Define the running policy of buildflow, which can be lazy or eager. The eager mode is used by default if this parameter is not defined.
    jobs: # Build tasks
      - job: Job3 # Assign a custom name to the child task.
        depends_on: # Define the task dependency. In this practice, the configuration indicates that Job3 depends on Job1 and Job2.
            - Job1
            - Job2
        build_ref: .cloudbuild/build3.yml # Define the YAML build script to run during a job build.
      - job: Job1
        build_ref: .cloudbuild/build1.yml
      - job: Job2
        build_ref: .cloudbuild/build2.yml
buildflows:
  - condition: p == 1 # All jobs under this collection are executed if this condition is met.
    jobs: # It defines the tasks to be orchestrated.
      - job: Job1 # Assign a custom name to the child task.
        build_ref: 1.yml # YAML build script that needs to be run during a build.
        params:
          - name: abc
            value: 123
      - condition: p == 1 # Job2 is executed if this condition is met.
        job: Job2
        build_ref: 2.yml
        params:
          - name: abc
            value: 123
  • lazy: A job with a higher priority is triggered first. After successful execution, a job with a lower priority is then triggered. The build takes a long time but saves resources. Therefore, you are advised to use this method when the number of parallel jobs is insufficient.
  • eager: All jobs are triggered synchronously. For jobs that depend on other jobs, prepare the environment and code first and wait until the dependency jobs are successfully executed. Resources may be idle, but the build time can be shortened. You are advised to use this mode when the parallel job quota is sufficient.

jobs

jobs is used to define jobs to be orchestrated. Each job must have a unique name as its identifier. If job A depends on job B, B has a higher priority. Jobs with the same priority are triggered synchronously.

The following is a code sample:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
 
    jobs:
     - job: Job3
       depends_on:
           - Job1
           - Job2
       build_ref: .cloudbuild/build3.yml
     - job: Job1
       build_ref: .cloudbuild/build1.yml
     - job: Job2
       build_ref: .cloudbuild/build2.yml

As shown in the preceding example, Job3 depends on and has lower priority than Job1 and Job2, which are triggered synchronously.

params

params can define global parameters to be shared by all jobs. You can also define parameters only for some jobs. Here is an example.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
 
buildflow:
    jobs:
      - job: Job3
        depends_on:
            - Build Job1
            - Build job2
        build_ref: .cloudbuild/build3.yml
      - job: Job1
        params:
          - name: isSubmodule
            value: true
        build_ref: .cloudbuild/build1.yml
      - job: Job2
        params:
          - name: isSubmodule
            value: true
        build_ref: .cloudbuild/build2.yml

As shown in the preceding example, global parameters (params) are not defined. Instead, the isSubmodule parameter is defined in Job1 and Job2.

During a build with YAML, parameters are used in the following priority (as shown in the preceding sample code):

Runtime parameters configured on the Parameters page > Default values of parameters configured on the Parameters page > Parameters defined in build_ref > Parameters defined in params under a job > Global parameters defined in params under BuildFlow