Configuring the Build Environment

Configure a global runtime environment for a build task.

CodeArts Build also allows you to use custom executors, such as LINUX, LINUX_DOCKER, WINDOWS, and MAC (Linux, Linux Docker, Windows, and macOS executors). For build scenarios supported by these executors, see Table 1.

**Table 1** Executor types and their description
Executor Type	Description
LINUX	You can run shell commands to run the build task on a Linux VM. Before using CodeArts Build, you need to install build tools, such as Maven and Gradle, on custom executors. Only the following build actions are available: Running Shell Commands, Uploading a Software Package to a release repo, and Downloading a Package from Release Repos.
LINUX_DOCKER	When you run the build task, CodeArts Build starts a Linux Docker container in which the task is run. The entire build process runs in the container. Once the task is finished, the container automatically removes the build image, which includes the code pulled during the build, the process data, and the build products. You can configure the mapping between the host directory and container directory to share the host directory in the image. All build actions are supported except for Build with MSBuild, and you do not need to install the build environment.
WINDOWS	You will run build tasks on the Windows executor. This allows you to execute Windows-related build tasks. You can use Git Bash to run the shell script for your build. Only the following build actions are available: Running Shell Commands, Uploading a Software Package to a release repo, and Downloading a Package from Release Repos. You can use Windows 7, Windows 10, Windows Server 2012, or Windows Server 2016. Before customizing a Windows executor, ensure that you have installed the JDK and Git. Install the compilation tool. For example, install Maven if you will use it for your build.
MAC	You will run shell commands on the macOS executor for your build. This allows you to execute macOS-related build tasks. Only the following build actions are available: Running Shell Commands, Uploading a Software Package to a release repo, and Downloading a Package from Release Repos. You can select any macOS version in use.

Build on GUI

CodeArts Build presets the Configure Build Environment action. Set the parameters according to Table 2.

**Table 2** Build environment parameters
Parameter	Description
Environment	x86/Kunpeng (Arm) server NOTE: Select the appropriate type of host you intend to use for software running on different chipset architecture. Your software will run better on a server using the same architecture. Kunpeng servers are Arm-based.
Execution Host	Select the compute resource used to run your build task. In CodeArts Build, virtual machines (VMs) are used. Executors can be built-in or custom executors. Built-in executors: Provided by CodeArts Build with out-of-the-box availability. The default executor specifications are 2 vCPUs and 8 GB memory. Custom executors: Compute resources provided by users. They can be hosted in CodeArts Build after registration. CodeArts Build schedules these executors to run build tasks. For details, see Table 1. You can select a built-in or custom executor. A custom executor is the agent executor added to the agent pool. For details about how to customize an executor, see Agent Pools.
Mapping Between Host and Container Directories	Set up the directory mapping between the custom executor and the container, and then you can mount files like dependencies from the custom executor to the container for your builds. (This mapping needs to be set when Execution Host is set to Custom executor.) If the Host Directory is set to /home and the Container Directory is set to /opt, then the content in the executor's local /home directory will be mounted to the /opt directory in the container.

Build with Code

Modify env settings in the YAML file by referring to the following sample code of build environment configurations.

    
         version: 2.0 # The version number is a mandatory and unique parameter that must be set to 2.0.
env: # Optional. It defines the build environment. 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 # The host type of the build environment can be 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.

Add the following code information to the YAML file for your code-based build by referring to the following sample code of BuildSpace.

You have an available environment with custom executors.

version: 2.0
buildspace: # BuildSpace is used.
  fixed: true
  path: kk  
  clean: true
  clean_exclude:
    - cache # Excluded path
    - aa # Excluded path
    - bb # Excluded path

**Table 3** Parameters in the sample code of BuildSpace
Parameter	Type	Description
fixed	String	Optional. In CodeArts Build, an empty path (for example, /devcloud/ws/sMMM/workspace/j_X/) is randomly assigned to a build task as the root directory by default. This directory is called a "BuildSpace". Even for build tasks in the same project, BuildSpaces are randomly assigned to them. However, a fixed BuildSpace path is necessary in some scenarios. CodeArts Build allows users to configure BuildSpace to specify a fixed directory for a build. true: A fixed path is used. false: A random path is used. The default value is false.
path	String	Optional. The fixed path is in the following format: */opt/cloud/slavespace/usr1/+"${domainId}"+/. You can set the path* parameter to add a path after the fixed path. For example, if the path is set to kk, the fixed path is */opt/cloud/slavespace/usr1/+"${domainId}"+/kk*.
clean	String	Optional. true: The fixed path will be cleared. Files in the fixed path will be deleted each time the build task is complete. false: The fixed path will not be cleared. When the total size of files reaches the maximum capacity of the workspace, you need to manually free up space by setting clean to true. NOTE: If there is no clearance setting for the fixed path, all files within the current tenant's fixed path will be automatically deleted once the total file size reaches the upper limit of the workspace. The workspace refers to the custom executor specification. The default value is true.
clean_exclude	String	Optional. Specify paths to exclude from the cleanup. Only level-1 folders in a fixed path can be specified.