Crafting Your build.yml for Multiple Tasks

A build task represents the smallest execution unit in straightforward service scenarios. However, as your requirement grows in complexity, a single task may no longer suffice. In those cases, you may need to:

Coordinate interdependent build tasks spanning multiple repositories by distributing them across 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 concurrently based on their dependencies.

Tutorial Video

This video describes how to run a Maven build project (or task) that includes multiple child tasks.

The following is a YAML file example for multiple tasks:

   
    
      
      
        version: 2.0 # The version number is required and must be set to 2.0.
params: # Define global parameters that apply across all child tasks.
  - name: p
    value: 1
# Both env and envs are optional. Use envs if you need conditional logic to determine which host specification or type should be applied.
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 # Specify the agent pool type. The value can be docker or custom. Set this value to docker to run your build on a default executor, or choose custom when using a custom executor.
    arch:X86 # Specify the host architecture for the build environment. Select either x86 or Arm.
    class:8U16G # Define the specification, which can be 2U8G (2 vCPUs | 8 GB), 4U8G (4 vCPUs | 8 GB), 8U16G (8 vCPUs | 16 GB), 16U32G (16 vCPUs | 32 GB), or 16U64G (16 vCPUs | 64 GB). This parameter is not required when type is set to custom.
    pool:Mydocker #Set the agent pool name. This parameter is required when type is set to custom.
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 conditional logic to determine how jobs are executed.
buildflow:
 strategy: lazy # Set buildflow's execution policy to either lazy or eager. If not specified, it defaults to eager mode.
         # lazy: This mode triggers high-importance child tasks first. Once those succeed, downstream child tasks kick off. This policy helps conserve build resources when concurrency is tight. However, the overall build time can run longer.
         # eager: This mode triggers every child task at the same time. Dependents will prepare the environment and code and then wait for their prerequisite builds. Although resources may spend time on idle waiting, this policy slashes build time when you have plenty of concurrency capacity.
    jobs: # Define child tasks to be orchestrated. Each child task must have a unique name as its identifier. If child task A depends on B, B has a higher priority than A. Child tasks with the same priority are triggered at the same time. This example defines three child tasks: Job1, Job2, and Job3. Job3 depends on Job1 and Job2 and will be run only after they are completed. Job1 and Job2 have equal priority and will be triggered at the same time.
      - job: Job3 # Assign a custom name to the child task.
        depends_on: # Define the dependency within the job block. 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 run by a job.
      - job: Job1
        build_ref: .cloudbuild/build1.yml
      - job: Job2
        build_ref: .cloudbuild/build2.yml
buildflows:
  - condition: p == 1 # All child tasks under the following jobs collection are executed if this condition is met.
    jobs: # Define the tasks to be orchestrated.
      - job: Job1 # Assign a custom name to the child task.
        build_ref: 1.yml # Define the YAML build script to be run during the build process.
        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

       

     

   
  

In the code sample above, parameters are referenced according to the following priority order:

At the top of the hierarchy are runtime parameters specified on the Parameters page, followed by the default values configured on the same page. Next in priority are the parameters declared within build_ref, followed by those defined in the params block of an individual job. At the base of the hierarchy sit the global parameters defined in params in BuildFlow.

For tailored performance per scenario, you may define params in a different way:

You can configure params as global parameters that apply to all child tasks. If you demand job-specific parameters rather than params at the top, you can scope parameters directly inside your desired child tasks. The following code scopes parameter isSubmodule to Job1 and Job2.

   
    
      
      
        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

       

     

   
  