CodeArts Build Basics

Build refers to the process of compiling source code into one or more object files, and packaging these object files along with configuration and resource files.

CodeArts Build provides an easy-to-use, cloud-based build platform that supports multiple programming languages, helping you achieve continuous delivery with higher efficiency. With just a few clicks, you can easily create, configure, and run build tasks to automate code retrieval, build, and packaging. CodeArts Build also monitors build status in real time.

CodeArts Build allows you to build using either the graphical user interface (GUI) (graphical build) or YAML files (code-based build).

Graphical Build

CodeArts Build provides various build tools that you can select and coordinate as needed. If the preset build tool versions do not meet your needs, you can also customize your own environments. Then you can package them into a Docker image and push it to any SoftWare Repository for Container (SWR) repositories for later use.

Code-based Build

(You can only select "Repo" as the code source for code-based build.)

To configure your build script, start by defining your build environments, parameters, commands, and tools in a YAML file named build.yml. Then add this file and the source code to a code repository. The build.yml file will serve as the script that the system uses to run a build, making the process traceable, recoverable, secure, and reliable. Pros of YAML builds are as follows:

Your YAML file clearly describes build parameters, commands, steps, as well as post-build operations, ensuring a trusted build process.
The build.yml configuration corresponding to the current commit is used for each build to ensure that the build can be restored and traced. You do not need to worry that the previous task cannot be executed repeatedly due to build configuration modification.
If the build script needs to be modified for a new feature, you can create a branch to modify the build.yml file for testing without worrying about affecting other branches.

You can configure either a single task or multiple tasks in YAML builds.

YAML File Structure for a Single Task

This example uses a YAML file to run a Maven build task.

     version: 2.0 # The value must be 2.0. This version number is mandatory and unique.
params: # Build parameters that can be referenced during your build. If no build parameters are set here, those created during task configuration are preferentially used.
  - name: paramA
    value: valueA
  - name: paramB
    value: valueB
env: # Defines the build environment. Optional. x86 is used by default if neither env or envs is set.
  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 # Host type of the build environment: 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.
steps:
  PRE_BUILD: # Used to prepare for building, for example, downloading code and executing shell.
    - checkout:
        name: Code download # Optional
        inputs: # Action parameters
          scm: codehub # Code source: CodeArts Repo only
          url: xxxxxxxxx # SSH address for the URL to pull code
          branch: ${codeBranch} # Pulled code branch, which can be parameterized.
    - sh:
        inputs:
          command: echo ${paramA}
  BUILD: # Defines the build action. Only one BUILD can be configured. For code examples of different build actions, see the code-based build part of each action.
    - maven: # Action keyword. Only specified keywords are supported.
	name: maven build # Optional
	image: xxx # You can specify an image path. For details, see the following description.
	inputs:
	  command: mvn clean package
    - upload_artifact:
	inputs:
          path: "**/target/*.?ar"
 
 
  

YAML File Structure for Multiple Tasks

A build task is the minimum unit and applies to simple service scenarios. Build tasks may not meet complex requirements. For example:

A multi-repo approach distributes build tasks that depend on each other across multiple machines.
You want to split build task in a more modular and fine-grained manner and execute the build jobs in a sequence complying with their dependencies.

In the preceding build scenarios, BuildFlow can be used to assemble multiple interdependent build tasks in directed acyclic graph (DAG) mode. BuildFlow will parallelly execute these build tasks based on their dependency relationship.

The following is a YAML file example for multiple tasks:

     version: 2.0 # The value must be 2.0. This version number is mandatory and unique.
params: # Build parameters, which can be referenced during a build.
  - name: p
    value: 1
# env and envs are optional. Configure envs if you need a condition 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 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 # Host type of the build environment: 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. Configure buildflows if you need a condition 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 task
      - job: Job3 # Job name, which can be customized.
        depends_on: # Define the job dependency. In this example, Job3 depends on Job1 and Job2.
            - Job1
            - Job2
        build_ref: .cloudbuild/build3.yml # Define the YAML build script to run during a job.
      - 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: # Defines the task set to be orchestrated
      - job: Job1 # Job name, which can be customized.
        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 simultaneously. 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 simultaneously.

The following is a code sample:

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

params

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

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