摘要：本文讲解如何为 BSP（板级支持包）搭建完整的 CI/CD 流水线。核心思路是：Git push 触发分层 CI——先跑 Fast CI 快速反馈，再跑 Full BSP CI 覆盖 Build Matrix，最后用 Hardware CI 验证真实硬件；通过固定 Docker 构建环境、版本化 Toolchain、Kconfig/Devicetree 校验、内存检查、Artifact 与 Release 分离、Git Tag 驱动发布等机制，最终形成可长期维护、可验证、可自动发布的 BSP 产品闭环。
BSP CI/CD：如何让 Git Push 自动 Build、Test、Release？
前面40～42我们已经把公司 BSP 的：
生命周期 Repository Architecture Versioning&Release Management串起来了。
这一篇继续往前走一步：
代码一旦 git push，公司 BSP 能不能自动 Build、自动 Test、自动生成 Release Artifact，最后把一个“可交付 BSP”发布出来？
答案是：可以，而且这其实是公司 BSP 从“工程项目”走向“产品”的关键一步。
一、先看最终目标
我们希望最终达到这样的工作流：
Developer │ │gitpush ▼ Git Repository │ │ CI Trigger ▼ ┌──────────────────────────────┐ │ CI Pipeline │ │ │ │1. Checkout │ │ ↓ │ │2. Prepare Toolchain │ │ ↓ │ │3. Build │ │ ↓ │ │4. Static Analysis │ │ ↓ │ │5. Unit Test │ │ ↓ │ │6. BSP Validation │ │ ↓ │ │7. Package │ │ ↓ │ │8. Artifact │ └──────────────┬───────────────┘ │ ▼ Release / Registry │ ▼ BSP v1.4.0也就是说：
Git 不再只是保存代码，而是成为 BSP 产品生产线的入口。
二、为什么 BSP 特别需要 CI/CD？
普通软件项目：
source code ↓ build ↓ testBSP 要复杂得多：
BSP ├── SoC ├── Board ├── Devicetree ├── Kconfig ├── Clock ├── Reset ├── UART ├── GPIO ├── SPI ├── I2C ├── Timer ├── Interrupt ├── Linker ├── Startup ├── HAL ├── Drivers ├── Toolchain └── Board configuration因此一个 BSP 的问题可能非常隐蔽。
例如：
UART Driver 修改 ↓ Build OK ↓ Unit Test OK ↓ Board boot 失败或者：
Linker script 修改 ↓ Compile OK ↓ Link OK ↓ Firmware size 超出 Flash甚至：
Devicetree 修改 ↓ 某些 board build OK ↓ 另一个 board build 失败所以 BSP CI 的核心不是：
“代码能不能编译？”
而是：
“这个 BSP 的整个支持矩阵有没有被破坏？”
三、BSP CI 最重要的概念：Build Matrix
公司 BSP 通常不是：
1SoC1Board1Configuration而是：
SoC Family │ ├── SoC-A │ ├── Board-A1 │ └── Board-A2 │ └── SoC-B ├── Board-B1 └── Board-B2再加：
Toolchain ├── GCC └── LLVM Build configuration ├── debug ├── release └── minimal最终形成：
GCC LLVM │ │ ┌────────┴──────────┴──────┐ │ │ Board-A1 Board-A2 │ │ debug/release debug/release这就是：
Build Matrix
四、不要一开始就测试所有组合
如果：
4SoC ×8Board ×3Configuration ×2Toolchain就是：
4×8×3×2=192builds每次 Git push 都跑 192 个 build：
Developer │ git push │ ▼192jobs │ └── 等待1小时开发体验会非常差。
所以 BSP CI 通常分层。
五、第一层：PR / Push Fast CI
目标：
几分钟内告诉开发者：这个 patch 有没有明显破坏 BSP。
例如：
PR │ ├── formatting ├── compile ├── Kconfig validation ├── Devicetree validation ├── static analysis └── basic tests典型：
10～30 个关键 build而不是全部。
六、第二层：Full BSP CI
例如：
main │ ▼ Full Matrix │ ├── SoC-A │ ├── Board-A1 │ ├── Board-A2 │ └── Board-A3 │ ├── SoC-B │ ├── Board-B1 │ └── Board-B2 │ └── SoC-C └── Board-C1这个可以：
nightly或者：
merge to main之后运行。
七、第三层：Hardware CI
这是 BSP CI 最有价值的一层。
因为：
Build ≠ Hardware works例如：
CI Server │ │ USB ▼ ┌─────────────┐ │ Test Runner │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Company SoC │ │ Development │ │ Board │ └─────────────┘然后：
Build ↓ Flash ↓ Reset ↓ UART ↓ Test ↓ Result例如 BSP 最基本的 hardware smoke test：
Boot ↓ UART output ↓ GPIO ↓ Timer ↓ Interrupt ↓ Reboot八、因此 BSP CI 最好分成 4 层
可以建立一个非常清晰的模型：
BSP CI │ ┌─────────────┼──────────────┐ │ │ │ Compile Static Test │ Analysis │ │ │ ▼ ▼ Build Matrix Hardware CI进一步：
Level1Syntax / Format ↓ Level2Compile / Link ↓ Level3Software Test ↓ Level4Hardware Test九、一个 BSP Git Push 到底发生什么？
假设：
gitpush origin feature/uart-fixGit server 收到：
push event然后：
CI triggerPipeline：
Checkout ↓ Environment ↓ Dependency ↓ Build ↓ Test ↓ Package十、第一步：固定 Build Environment
这是 BSP CI 非常重要的一点。
千万不要：
CI Server ↓ apt install...↓ 不知道今天装了什么因为：
今天 build OK 明天 build fail可能只是：
compiler version changed所以最好：
Docker Image例如：
company/bsp-build-env:2026.09里面固定：
Ubuntu GCC CMake Python west dtc ninja clang下面是一个示例 Dockerfile，用来构建company/bsp-build-env:2026.09镜像：
# company/bsp-build-env:2026.09 # 固定 BSP CI 构建环境：Ubuntu + GCC + CMake + Python + west + dtc + ninja + clang FROM ubuntu:24.04 # 基础系统工具 RUN apt-get update && apt-get install -y --no-install-recommends \ build-essential \ git \ curl \ ca-certificates \ python3 \ python3-pip \ python3-venv \ ninja-build \ device-tree-compiler \ clang \ && rm -rf /var/lib/apt/lists/* # 安装 west（Zephyr 工作流工具） RUN pip3 install --no-cache-dir west # 安装 CMake（固定版本，避免漂移） RUN pip3 install --no-cache-dir cmake==3.30.0 # 安装 ARM GCC 工具链（固定版本） RUN curl -fsSL https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz \ | tar -xJ -C /opt \ && ln -s /opt/arm-gnu-toolchain-14.2.rel1-x86_64-arm-no
