张国锋-RT-Thread仓库中使用YML为BSP实现CI守护.pptx

1、,RT-Thread仓库中使用YML为BSP实现CI守护,主讲人：,2025.6,张国锋,时间：,RT-Thread的CI/CD 流水线简介,BSP 构建工作流,构建矩阵生成,目录,单个BSP的构建,构建产物管理,如何添加BSP到构建CI,PART.,01,RT-Thread CI/CD 流水线简介,RT-Thread 的 CI/CD 流水线基于 GitHub Actions 构建，主要实现了自动化构建、测试及产物生成。通过多个独立的 GitHub Actions 工作流，开发者能够高效地验证代码变更，保障项目质量。,定义,RT-Thread的CI/CD 流水线简介,RT-Thread的CI/

2、CD 流水线简介,本次主要分享的工作流是RT-Thread BSP Static Build Check，主要用于BSP编译验证其核心原理在于：通过定制.github/workflows 目录下的 YAML 文件定义工作流，实现批量模拟开发者手动编译 BSP 的过程。,定义,PART.,02,BSP 构建工作流（BSP Building Workflow）,提交 Pull Request,修改的 BSP 自动触发构建，用于代码审查前的自动检查。,代码推送到 master,构建所有 BSP，确保主分支稳定性。,触发场景,定时触发,每天定时触发一次全量构建,手动点击触发,用于发布前的全面验证,工作

3、流流程介绍,右图展示了该工作流的核心运行流程。PR 触发是最常见的场景：当开发者提交 PR 后，CI 系统会分析修改的文件路径，动态判断本次构建是执行全量编译还是增量编译。随后，利用 GitHub Actions 的矩阵策略，并发创建所需的多个 BSP 编译任务。最后，系统并行地对这些 BSP 进行编译。这种机制能快速发现潜在的编译错误或配置问题，显著提升问题定位效率。,PART.,03,构建矩阵生成,构建矩阵,GitHub Actions 的矩阵策略主要用于生成多个 BSP 的并行编译作业。默认情况下，CI 会读取.githubALL_BSP_COMPILE.json 文件以获取需要编译的

4、BSP 列表，该文件同时包含了各个 BSP 所需的工具链名称。该 JSON 文件本身采用矩阵结构。CI 读取后会根据其中定义的组名创建相应的并发编译任务。所以通过修改传入JSON格式的数据就可以实现对特定 BSP 的编译。,获取文件变更生成构建矩阵,通过 JSON 配置文件，可以在每次 PR 提交时，自动触发对配置中所列 BSP 的构建。然而，随着 BSP 数量的增长，CI 执行时间会显著延长。特别是当 PR 仅涉及某个特定 BSP 的局部修改（且不影响内核）时，这时进行全量编译显然就会导致效率低下。,获取文件变更生成构建矩阵,为解决此问题，可通过分析 PR 提交分支与主分支间的差异（git

5、diff）来确定修改的文件。提取文件路径后，与 JSON 配置文件中的 BSP 信息进行匹配筛选，最终生成一个仅包含需要重新编译的 BSP 的列表。该列表将作为矩阵参数传递给后续的构建工作流，从而实现按需编译。,根据文件变更显示修改状态(拓展),在引入git diff 功能的基础上，可进一步实现文件状态显示功能。该功能将 PR 中的文件变更整理成一份清晰的状态报告，便于评估本次 PR 的修改规模及其主要内容概览。,PART.,04,单个BSP的构建,RT-Thread的编译流程介绍,当构建矩阵传入 BSP 构建任务后，GitHub Actions 会为矩阵中的每个 BSP 创建对应的独立任务。

6、这些任务执行的核心流程相同，但不同 BSP 间存在特定差异（例如使用的工具链）。下文将以单个 BSP 为例用来说明其编译流程。,RT-Thread的编译流程介绍,在构建过程中首先需要下载对应的工具链这里用到了一个GitHub Actions Cache机制主要功能是将下载的文件进行缓存，这样当下次需要用到的时候就会从缓存存储的地方获取如下图所示,RT-Thread的编译流程介绍,在由矩阵创建的每个独立任务中，均包含了该任务所需编译的 BSP 路径。此路径将作为参数，随其他必要信息一同传递给编译脚本 tools/ci