摘要：本文讲解如何为 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 VersioningRelease 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