新建构建任务（代码化构建）

约束与限制

代码化构建仅支持使用CodeArts Repo代码仓。

新建构建任务前准备工作

• 已具备CodeArts Repo服务的操作权限。
• 已参考代码托管服务（CodeArts Repo）的“用户指南 > 创建 > 代码托管仓库”，新建代码仓库。
• 参考软件开发生产线(CodeArts)的“用户指南 > 软件开发生产线（CodeArts）使用前准备 > 新建CodeArts项目”，新建CodeArts项目。

  如果已有项目，无需执行此步骤。

创建代码化构建使用的YAML文件

1. 通过项目入口方式访问CodeArts Build服务首页。
2. 选择导航栏“代码 > 代码托管”，进入代码托管页面。
3. 单击“新建仓库”，选择“普通仓库”，单击“下一步”，根据表1填写参数后，单击“确定”。

   表1 新建代码仓

   参数	说明
   代码仓库名称	自定义代码仓名称。例如：maven_yml_build。 以数字、字母或者“_”开头。 可包含“.”和“-”。 不能以“.git”、“.atom”或者“.”结尾。
   描述	可选参数。对代码仓的描述。
   选择gitignore	可选参数。根据编程语言选择“.gitignore”，例如：Java。
   初始化设置	勾选全部。 允许项目内人员访问仓库：选择后会自动将项目中的项目经理设为仓库管理员，开发人员设为仓库普通成员。当项目新增这两个角色时，也会自动同步到已经存在的仓库中。 允许生成README文件：可以通过编辑README文件，记录项目的架构、编写目的等信息，相当于对整个仓库的一种注释。 自动创建代码检查任务（免费）：仓库创建完成后在代码检查任务列表中，可看到对应仓库的检查任务。
   可见范围	设置为“私有”。 私有：仓库仅对仓库成员可见，仓库成员可访问仓库或者提交代码。 公开只读：仓库对所有访客公开只读，但不出现在访客的仓库列表及搜索中，您可以选择开源许可证作为备注。

4. 单击“新建 > 新建目录”，目录命名为“.cloudbuild”。
5. 在“.cloudbuild”目录下依次单击“新建 > 新建文件”，文件命名为“build.yml”，新建后文件目录如图1所示。
   图1 文件目录
   

   若YAML文件不存放在“.cloudbuild”目录，可通过“CB_BUILD_YAML_PATH”参数指定YAML文件在代码仓中的路径。参数配置可参考添加自定义参数的配置指导。

6. 单击，参考如下代码示例，编写“build.yml”文件。

   以下示例为使用内置X86、8U16G的执行机，使用Maven构建工具编译构建托管在CodeArts Repo中的代码，并上传软件包至软件发布库。

   不同构建步骤的代码示例，可参考配置构建任务中各个构建步骤的“代码化构建”部分。多任务YAML文件结构可参考多任务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

   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"

配置构建任务基本信息

1. 选择导航栏“持续交付 > 编译构建”，进入编译构建服务页面。
2. 单击“新建任务”，进入配置“基本信息”页面，参考表2填写构建任务基本信息。然后单击“下一步”，进入“构建模板”页面。

   表2 基本信息配置说明

   参数	说明
   名称	创建的编译构建任务名称，可自定义。 支持中英文，数字，下划线“_”和连接符“-”。 字符长度范围为1~115。
   所属项目	创建的编译构建任务所属项目。 以项目入口方式访问访问编译构建服务时默认填写，无需手动填写。 以服务入口访问时需根据实际情况选择新建构建任务前准备工作中创建的项目。
   代码源	选择Repo：表示从代码托管拉取代码进行构建。
   代码仓	选择实际需要编译的代码仓。
   默认分支	选择仓库默认分支。
   描述	可选参数。根据实际场景对编译构建任务的描述。字符长度范围0~512。

选择构建模板

在构建模板页面选择“空白构建模板”。选择后单击“确定”，进入“构建步骤”页面。

说明：

使用代码化构建时，选择任何构建模板都不影响使用YAML构建。

配置构建步骤

在“构建步骤”页面左上角单击“代码化”页签，系统会从配置构建任务基本信息中配置的代码仓库及分支中，自动读取YAML文件。

您可在此处参考配置构建任务中“代码化构建”部分的代码示例对YAML文件进行修改。如果在此处修改了YAML文件，那么执行构建任务后，修改后的内容会覆盖创建代码化构建使用的YAML文件中的原YAML文件。

配置完成后，单击“保存”，即可完成构建任务的创建。

多任务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中定义的全局参数。