📌 CICD 流程接入社区标准的几点疑问（请各位大佬指正）

CICD SIG
1

:pushpin: 关于 CICD 构建流程的几点疑问（请社区大佬指正）

各位社区大佬好，我们有几个关于自己 CICD 构建流程的问题想请教，也请多多体谅我们目前理解可能还不够深入：

:one: 每日构建是否需要转测？

我们目前的理解是：我们自定义的每日构建，每天都会基于相同的 manifest 版本进行一次完整构建。

想咨询下社区的最佳实践：

  • :backhand_index_pointing_right: 这种每日构建是否也需要走“转测”流程？
  • :backhand_index_pointing_right: 还是说每日构建的主要目的是验证构建流程和稳定性，而不需要每次都转测？

:two: 我们自己理解的每日构建基于相同 manifest 是否流程设计上有问题？

目前我们的每日构建是每天构建完全相同的 manifest 版本，因此我们也在思考：

  • :backhand_index_pointing_right: 这种方式本身是否就存在流程设计上的问题？
  • :backhand_index_pointing_right: 是否每日构建应该基于某种策略动态选取 manifest？

原谅我们这边对流程理解不精，我们也希望尽快对齐 OpenUBMC 的社区构建标准。如果有什么明显的理解偏差，还请社区大佬指出，我们会及时调整。

:three: 关于 PR 合并后的构建与 Review阻塞流程

我们当前的版本构建流程如下：

  • PR 创建后触发版本构建；
  • 构建过程中会执行单元测试；
  • Gitea 设置了“多位 reviewer 通过”后才能合并 PR。

这块我们有以下疑问：

  • 是否应该在单元测试之后，通过“阻塞流水线线程”的方式强制等待人工 Review？
  • 是应该在单元测试后先合并 PR 再触发构建整包hpm包，还是整包构建结束后再 Review？
  • “整包hpm构建”放在PR 合并后组件上conan库后“再执行全量整包构建”，还是说放在每日构建的一部分？
    如果是单组件 PR 做版本构建，走单元测试，review上conan库后，manifest 没有改动，是不是就无法实现整包 HPM 包构建？

此外，HPM 包的生成属于版本构建，还是每日构建？
如果版本构建阶段已经生成了 HPM 包，那每日构建是否还有额外意义？

:four: 关于 PR 与大版本的理解

我们目前尚未进行大版本发布，仅做周期性构建。

  • 那未来如果需要同步社区升级，是不是我们尽量不要自己定义大版本？
  • 如果我们有较大的改动，是否建议以 PR 的形式提交给社区，由社区统一管理版本合入与构建？

:white_check_mark: 总结

我们现在整体感觉整个流程还有不少模糊点，很多地方可能是我们自己理解不清导致的“低级错误”。
希望通过这次请教，能进一步厘清我们的构建策略，并更好地对齐社区的标准流程，做好后续的协同工作。

非常感谢各位大佬的耐心指导与支持 :folded_hands:

2

如果我们只是针对某个组件提了 PR（例如单个组件的代码改动），同时也没有改动该组件自身的版本号，那是不是意味着：

每个组件的版本其实是由某个字段指定的，并且需要在 manifest 中显式同步引用？
:point_right: 如果组件修改了版本号，但没有更新 manifest，是否就不会触发新的整包构建？

换句话说：

  • 如果仅在组件层面有 commit 改动，也没有更新某个关键版本字段，manifest 本身也未发生变化 ——
    那这种场景是否不属于“版本构建”流程，而会被归入每日构建？
  • 还是说，即便组件改动未显性更新 manifest，构建系统也需要某种检测机制可以识别为版本构建？

我们目前对 manifest 与整包构建流程之间的联动机制还理解不够，希望能再请社区大佬帮忙指点一下

3

问题一：每日构建是为了验证组件变化后，各个单板的各种类型包是否能正常构建。能正常出包不代表在环境中能正常使用，每日构建走转测的目的在于验证hpm包在环境中是否正常使用。所以是manifest中定义的组件版本号发生变化就需要进行每日构建，并走转测流程的。
问题二：manifest中组件没有变化时，可以省去每日构建。每日构建主要用于验证manifest发生变化时，是否存在出包问题。
问题三：组件合并PR的流程是：提交PR—在门禁中进开发者测试，和组件conan包构建，其他代码检查等（不涉及hpm包构建）—门禁通过后，reviewer加分—合并PR。合并之后，修改manifest中定义的组件版本号，在manifest门禁中会进行整包构建（但并非全量整包构建）。须在每日构建中进行全量整包构建。

4

组件版本在service.json文件中定义，社区组件根据commitID打tag并发布组件的conan包。整包构建是基于manifest的，manifest根据conan仓获取对应版本的组件。因此，如果组件此次commit没有修改版本，且组件发布没有带上此次commit，是不会影响整包构建的。

5

感谢详细解答，帮助我们澄清了每日构建与转测的边界。我们进一步整理了 CICD 流程，目前仍有一点关于版本构建和 manifest 门禁环节的问题想请教：

:question: 1. 组件合并 PR 属于“版本构建”吗？

目前我们的理解是：

  • 组件 PR 合并时，会触发该组件的构建、测试、conan 发布等，这是属于“版本构建”阶段；
  • 但这一步不会触发整包构建和 HPM 包生成。

→ 这种理解是否正确？这一步是否可以定义为社区标准流程中的“版本构建”？

:question: 2. manifest 门禁是否需要手动提交？

社区提到：“合并 PR 后需要修改 manifest 组件版本号，manifest 门禁中会触发整包构建”。

→ 这里我们理解为：组件 PR 合并后，还需额外提交一个 manifest 的 PR，更新相应组件的版本号，这一步才会触发整包构建。

→ manifest PR 也是走 review / 门禁流程？这个流程是全量构建还是仅构建受影响组件的整包？

:question: 3. 整包构建是否就是指单板的组件构建？

我们当前理解是：

  • manifest PR 合并后，触发的“整包构建”其实并不是编译所有组件，是就是单独编译单个组件吗，那这个版本构建要触发转测吗；
  • 真正“全量整包构建”是在每日构建中完成的。

→ 这种理解是否正确？也就是 manifest 门禁阶段的整包构建 ≠ 全量构建，而是按需构建？

6

第二个问题增加答复：

社区采用了两级流水线开发流程：

  1. 第一级是组件组，负责开发和发布组件新版本，输出的是一个个组件包；
  2. 第二级是产品级，需要集成第一级发布的组件，完成功能验证后合入manifest仓，更新产品配套表。

产品级未采用自动更新manfiest的方案，原因是多方面的，一是受限于自动化测试和验证时间太长，无法在PR门禁任务执行时间（如10分钟）内完成全量验证；二是要给组件留下足够的测试验证时间，避免组件发布即被集成，如某些功能涉及多个组件变更，需要多个组件一起上库，所以需要开发者自主规划版本合入计划和配套关系。

PR创建后需要触发产品构建，确保能够出包，而且为确保整包构建完整，可以将涉及的单板和包都全量构建一次。

伙伴可以实现动态生成manifest：需要伙伴写一段脚本，流程是下载manifest仓，自动更新subsys目录下的组件版本，更新的方法是去conan仓以组件名称为关键字，查询组件的最新版本，更新到manifest.yml，最后构建出产品包。

manifest仓的变更比较难检视，内部有一段脚本会自动比对manifest仓变更前后的组件差异，提取每个组件的详细变更点，以PR评审的方式显示在manifest的合入提交中，伙伴可以借鉴这个思路。

第三个问题

版本构建和每日构建是两个不同概念：

  1. 版本构建的目标是按产品的述求构建出所需要的软件包，如烧片包、装备包、现网包等。
  2. 每日构建是持续集成的概念，通过每日构建覆盖软件的构建出包和测试验证，质量看护。

第四个问题

伙伴自己的产品版本由伙伴自己定义，社区并无要求。不过建议基于社区版本增量定义，可以直观看出与社区版本的关系，如社区版本是25.00.00.01，我们可以定位25.00.13.01，其中13可以标记伙伴自己，01表示某个产品。
社区的版本是有支持周期的，建议伙伴在产品规划时明确自己基于社区的某个发布版本增量开发，如果社区版本的支持周期不满足或需要新功能时，需要升级社区版本，

能回合社区的，建议提交PR合到社区，一是可以让社区帮忙看护质量，二是减少社区版本更新时对本地分支的影响。

7

1、组件PR合入时，会有门禁检测是否能够成功构建出conan包，这个步骤只起到检测的作用，与组件发布无关。组件PR合并后，不会自动触发组件conan发布，需要手打打tag之后才会触发conan发布（目前只有committer和maintainner可以打tag）。
2、manifest是出整包的代码仓，manifest的门禁和组件门禁不同，manifest的门禁会检测能否构建出hpm包，但是在门禁中只执行了部分整包构建，并未进行全量整包构建的检查。同上，所有的门禁都只是检查能否正常构建以及代码正确性检查等，与发布无关。manifest的PR也要执行门禁，review后再合入的流程。
3、组件构建指组件代码仓构建出的conan包；整包构建指制品仓manifest构建出的hpm包。在制品仓manifest中支持定义不同的单板，以及各单板构建不同类型包（比如升级包，烧片包，装备包等）的定义。制品仓manifest有修改时，需要进行转测。每日构建中是进行的全量整包构建。

2 个赞
8

注：本 CICD 流程说明整合自社区海军哥与 wnb 大佬的回复内容，结合实际操作流程进行梳理与归纳。

每日构建机制说明

一、每日构建的目的与触发条件

每日构建用于验证组件版本更新后，各单板的软件包是否能够成功构建，并确保构建产物在实际运行环境中的可用性。构建成功并不代表可正常部署使用，因此每日构建需配合转测流程，验证 HPM 包在环境中的使用情况。

当 manifest 中任一组件版本号发生变化时，需触发每日构建并执行转测流程；若组件版本无变更，则可跳过每日构建。

每日构建的核心作用是验证 manifest 变更后是否存在出包异常或环境不兼容问题。

每日构建是持续集成的一部分，强调对软件构建与部署质量的持续性看护。

版本构建机制说明

版本构建和每日构建是两个不同概念：

  • 版本构建：按产品的交付需求，构建出所需的软件包，如烧片包、装备包、现网包等；
  • 每日构建：作为持续集成环节，覆盖组件变更后的构建出包和测试验证，起到质量预警作用。

注：每日构建也可以构建出完整的产品软件包（如烧片包、装备包、现网包等），与版本构建在构建产物上并无差异。

  • 若将“构建”定义为仅编译出包，则每日构建和版本构建等价，产物相同；
  • 若将“构建”定义为编译出包 + 自动化测试验证，则两者区别在于测试覆盖范围：每日构建通常仅执行部分用例以兼顾效率与资源，而版本构建需执行全量用例。
  • 每日构建的软件包若测试通过，也可用于版本转测；版本测试通过后可作为正式发布版本。
  • 至于构建使用哪个分支，由产品自行决定，CICD 平台按产品指定的分支策略执行。

社区采用两级流水线开发流程：

一、组件级流水线

组件合并 PR 的流程如下：

  • 提交 PR；
  • 在门禁中执行开发者测试、组件 Conan 包构建、代码检查等（不涉及 HPM 包构建）；
  • 门禁通过后，Reviewer 加分；
  • 合并 PR。

说明：组件 PR 合入时的门禁仅用于验证是否能成功构建出 Conan 包，与组件发布无关。组件合入后不会自动触发发布流程，需由 committer 或 maintainer 手动打 tag 才会触发 Conan 包发布。

二、产品级流水线

  • 在组件 PR 合并后，修改 manifest 中组件版本号；
  • 提交 manifest PR，进入门禁流程，触发整包构建（但非全量构建）；
  • 最终由每日构建执行 全量整包构建，验证所有单板包是否可用，确保构建完整性。

说明：manifest 是整包构建的代码仓，其门禁机制与组件仓不同。manifest 的门禁会检测是否能构建出 HPM 包，但仅执行部分构建任务，未覆盖全部单板和包类型的构建检查。manifest 的 PR 同样需执行门禁并经评审后方可合入。

产品级流水线集成组件版本并完成功能验证，更新 manifest 仓，形成产品配套表。

产品级未采用自动更新 manifest 的方案，原因如下：

  • 自动化测试和验证时间较长，难以在 PR 门禁任务（如 10 分钟内）完成全量验证；
  • 需为组件留出充分的测试验证时间，避免组件刚发布即被集成；
  • 部分功能依赖多个组件协同修改，需开发者自主规划版本合入与配套节奏。

PR 创建后应触发一次产品构建，验证能否成功出包。为确保构建完整性，可对相关单板与包执行一次全量构建。

构建类型说明

  • 组件构建：指在组件代码仓中构建生成的 Conan 包；
  • 整包构建：指在 manifest 仓中构建生成的 HPM 包。

manifest 仓支持定义多种单板及其对应的包类型（如升级包、烧片包、装备包等）。manifest 有改动时需配合转测；每日构建中将执行全量整包构建。

附：伙伴建议（供参考）

伙伴可以通过编写脚本实现动态生成 manifest：流程为拉取 manifest 仓，自动更新 subsys 目录下的组件版本。更新逻辑为：以组件名称为关键字，查询 Conan 仓中对应的最新版本号并写入 manifest.yml，然后触发整包构建。

manifest 的变更内容不易人工比对，社区内部已有一段脚本支持自动对比 manifest 变更前后的组件差异，提取各组件的详细变更点，并在 PR 评审中展示，供审阅使用。伙伴可借鉴该思路。

注：本 CICD 流程说明整合自社区海军哥与 wnb 大佬的回复内容，结合实际操作流程进行梳理与归纳。

9

大佬好，我在梳理 CICD 流程后，放到评论区了。但是还是有以下疑问，想请确认：

当前版本构建（组件级+产品级流水线）在组件合入 manifest 后，需要进行构建和转测；而每日构建同样会基于 manifest 执行全量构建并走转测流程。两者流程上是否存在重叠？

进一步想确认：

  1. 每日构建是否是统一基于 main 分支的 manifest 执行构建和转测？
  2. 产品级流水线是否也会基于 main 分支，还是各产品维护独立分支？
  3. 如果产品构建和每日构建使用的是不同分支，是否意味着当前这块已经涉及到代码分支策略的差异设计？

  4. 海军哥：第二级是产品级，需要集成第一级发布的组件，完成功能验证后合入manifest仓，更新产品配套表。这个功能验证是什么,UT,IT,DT?还是转测？

10

注：本 CICD 流程说明整合自社区海军哥与 wnb 大佬的回复内容，结合实际操作流程进行梳理与归纳。

11

@xuhaijun @wnb

12

要补充或纠正一下，每日构建也可以构建出全量产品的软件包（如烧片、装备、现网等），区别在于：

  1. 如果构建定义为编译出包，那每日构建和版本构建是没有区别的，构建的产物是相同的。
  2. 如果构建定义为编译出包加自动化测试验证，考虑到测试效率和资源占用等因素，一般每日构建只执行部分用例，版本构建需要执行全量用例。每日构建的软件包经过测试后可以用于版本转测，版本测试通过后可以用于版本发布，

至于用哪个分支来跑构建，就完全就是产品自己定要求，CICD按产品要求执行就行。

13

当前评论区整理的 CICD 流程说明，已根据各位的回复内容进行了初步整合和修改。如海军哥这边还有需要补充或修正的地方，欢迎随时指出～:speech_balloon::+1: