使用编译构建服务前须知
编译构建是指将软件的源代码编译成目标文件,并和配置文件、资源文件等一起打包的过程。
编译构建服务(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中定义的全局参数。
更多编译构建服务信息请参考产品介绍。
编译构建基本操作流程