Crafting Your build.xml 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 concurrently based on their dependencies.
Tutorial Video
This video describes how to run a Maven build project (or task) with multiple dependency subtasks.
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 48 49 |
version: 2.0 # The version number is a mandatory and unique parameter that must be set to 2.0. params: # Define global parameters that apply across all subtasks. - 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. # lazy: prioritizes high-importance subtasks first. Once those succeed, downstream subtasks kick off. This policy helps conserve build resources when concurrency is tight. However, the overall build time can run longer. # eager: triggers every subtask 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: # defines subtasks to be orchestrated. Each subtask must have a unique name as its identifier. If subtask A depends on B, B has a higher priority. Subtasks with the same priority are triggered at the same time. This example defines three subtasks: 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 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 |
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
For tailored performance per scenario, you may define params in a different way:
You can configure params as global parameters that apply to all subtasks your orchestrated builds. If you demand job-specific parameters rather than params at the top, you can scope parameters directly inside your desired subtasks. The following code scopes parameter isSubmodule to Job1 and Job2.
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 |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot