使用编译构建服务前须知
编译构建是指将软件的源代码编译成目标文件，并和配置文件、资源文件等一起打包的过程。
编译构建服务（CodeArts Build）为开发者提供配置简单的混合语言构建平台，实现编译构建云端化，支撑企业实现持续交付，缩短交付周期，提升交付效率。支持编译构建任务一键创建、配置和执行，实现获取代码、构建、打包等活动自动化，实时监控构建状态，让您更加快速、高效地进行云端编译构建。
在软件开发生产线解决方案中，编译构建服务属于其中一个子服务，具体位置可参考产品架构。
图形化构建
编译构建服务预置了丰富的构建工具，您可以根据需要自定义组合。如果预置的构建工具版本无法满足您的使用需求，您也可以自定义构建环境，将所需环境打包制作成Docker镜像并推送至SWR镜像仓库后使用。
代码化构建
（代码化构建仅支持代码源为Repo。）
编译构建支持通过YAML文件配置构建脚本，您可以将构建过程需要用到的构建环境、构建参数、构建命令、构建工具等信息通过YAML语法编写成build.yml文件，并且将build.yml文件随着被构建的代码一起存储代码仓库，执行构建任务时，系统会以build.yml文件作为构建脚本执行构建任务，使构建过程可追溯、可还原，安全可信。功能优势如下：
- 清晰描述构建过程：构建参数、构建命令、构建步骤、以及构建后的操作，使构建过程可信。
- 每次构建使用对应当前commit的build.yml配置，保证构建可还原可追溯，不必担心因修改了构建配置而不能重复执行之前的任务。
- 如果新特性需要修改构建脚本，开发人员可以拉一个新的分支修改build.yml去测试，而不用担心影响其他分支。
单任务YAML文件结构说明
该示例为通过YAML文件执行Maven构建。
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 |
version: 2.0 # 必须是2.0，该版本号必填且唯一 params: # 构建参数，可在构建过程中引用。如果不填写，则优先使用配置构建任务参数中的构建参数 - name: paramA value: valueA - name: paramB value: valueB env: # 定义构建环境信息。非必填，如果不填写，默认使用X86 resource: type:docker # 资源池类型：docker或custom，其中docker表示使用默认执行机，custom表示使用自定义执行机 arch:X86 # 构建环境主机类型：X86或ARM class:8U16G # 规格：2U8G、4U8G、8U16G、16U32G或16U64G，当type为custom时无需填写该参数 pool：Mydocker #资源池名称，当type为custom时需要填写该参数 steps: PRE_BUILD: # 用于做构建前的准备，例如下载代码，执行shell等 - checkout: name: 代码下载 # 可选 inputs: # 步骤参数 scm: codehub # 代码来源:只支持Repo url: xxxxxxxxx # 拉取代码的ssh地址。 branch: ${codeBranch} # 拉取的代码分支：支持参数化。 - sh: inputs: command: echo ${paramA} BUILD: # 用于定义构建步骤，仅支持配置一个BUILD。不同构建步骤的代码样例，可参考配置构建步骤中各个构建步骤的代码化构建部分 - maven: # 步骤关键字，仅支持特定关键字 name: maven build # 可选 image: xxx # 可以自定义镜像地址，请看下方说明 inputs: command: mvn clean package - upload_artifact: inputs: path: "**/target/*.?ar" |
多任务YAML文件结构详解
在编译构建中，构建任务是构建的最小单元，适用于业务比较简单的场景，但是在有些复杂的构建场景下，构建任务可能并不能满足复杂的构建要求。例如：
- 多仓工程需要分布到多个机器上去构建，并且构建工程之间还存在一定的依赖关系。
- 希望更模块化、更加细粒度的拆分构建任务，并按照依赖顺序进行构建。
对于上述这类比较复杂的构建场景，编译构建支持使用BuildFlow将多个存在依赖关系的构建任务按照有向无环图（DAG）的方式组装起来，BuildFlow将会按照构建的依赖关系并发进行构建。
多任务YAML文件整体内容示例：
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 # 必须是2.0，该版本号必填且唯一 params: # 构建参数，可在构建过程中引用 - name: p value: 1 # env和envs配置为非必填项。当用户需要使用条件判断确定使用的主机规格与类型时，选择配置envs env: # 如果配置，则优先级最高。即在此处定义了主机规格与类型，则不使用构建环境配置中选择的主机类型和规格 resource: type:docker # 资源池类型：docker或custom，其中docker表示使用默认执行机，custom表示使用自定义执行机 arch:X86 # 构建环境主机类型：X86或ARM class:8U16G # 规格：2U8G、4U8G、8U16G、16U32G或16U64G，当type为custom时无需填写该参数 pool：Mydocker #资源池名称，当type为custom时需要填写该参数 envs: - condition: p == 1 # 主机规格与类型的判断条件，满足条件会使用以下主机规格与类型 resource: type: docker arch: ARM - condition: p == 0 # 主机规格与类型的判断条件，不满足条件则不使用以下主机规格与类型 resource: type: docker arch: X86 # buildflow和buildflows配置二选一。当需要使用条件判断执行的jobs时，选择配置buildflows buildflow: strategy: lazy # 定义buildFlow运行的策略，支持lazy和eager。如果没有定义，默认使用eager模式 jobs: # 构建任务 - job: Job3 # 子任务的名称，可自定义 depends_on: # 定义job的依赖,此处表示Job3依赖Job1和Job2 - Job1 - Job2 build_ref: .cloudbuild/build3.yml # 定义Job在构建过程中需要运行的yaml构建脚本 - job: Job1 build_ref: .cloudbuild/build1.yml - job: Job2 build_ref: .cloudbuild/build2.yml buildflows: - condition: p == 1 # 执行任务的判断条件，满足条件会执行以下jos中编排的所有子任务 jobs: # 定义需要进行编排的任务 - job: Job1 # 子任务的名称，可自定义 build_ref: 1.yml # 构建任务在构建过程中需要运行的yaml构建脚本 params: - name: abc value: 123 - condition: p == 1 # 执行子任务的判断条件，满足条件会执行Job2子任务 job: Job2 build_ref: 2.yml params: - name: abc value: 123 |
- lazy：先触发优先级高的子任务构建，优先级高的子任务执行成功之后，再触发优先级低的子任务。构建时间相对较长，但是可以节省构建资源，推荐在并发数不足时使用。
- eager：同步触发所有子任务的构建，有依赖其它任务的子任务会先准备好环境和代码，等待所依赖的任务构建成功。可能造成资源空闲等待，但是可以缩短构建时间，推荐在并发数足够大的情况下使用。
jobs详细介绍：
jobs用来定义需要进行编排的子任务，每个子任务都必须要有唯一的名字作为构建任务的唯一标识。且若子任务A依赖子任务B，则构建优先级B > A，优先级相同的子任务会同步触发。
代码示例如下：
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 |
如上示例，Job3依赖于Job1和Job2，即构建优先级Job1、Job2 > Job3，且Job1和Job2同步触发。
params详细介绍：
params可以定义全局参数，即所有子任务共享。编译构建也支持在部分子任务上定义参数使用，例如：
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 |
如上示例，未定义全局参数params，而是将参数“isSubmodule”直接定义在Job1与Job2中。
在使用代码化构建时，需注意参数使用的优先级，以上述代码示例为例：
构建任务参数设置中设置的运行时参数 > 构建任务参数设置中的参数默认值 >build_ref中定义的参数 > job下的params中定义的参数 > BuildFlow下params中定义的全局参数。
更多编译构建服务信息请参考产品介绍。
编译构建基本操作流程
