4. 持续集成环境搭建
座舱项目的持续集成与手机App的持续集成有本质差异：一次完整的构建往往要拉取数十GB的Android源码与高通平台代码，调用高通专有的编译与打包工具链，产出可刷写的镜像，再交给台架或实车验证。因此，CI环境搭建的核心不是“装一个Jenkins”，而是把调度工具、编译算力、容器化环境、高通工具链四件事组合成一条稳定、可复现、可扩展的流水线。
一、工具选型：Jenkins 与 GitLab CI 的分工
两者并非二选一，实际项目中常见组合是：GitLab 作为代码与评审入口，Jenkins 作为重构建与硬件相关任务的执行引擎。原因在于座舱CI的负载特征——构建耗时长（单次全量编译常达1～3小时）、需要独占大内存机器、需要访问License服务器和刷机台架，这些更适合由Jenkins的Agent标签与并发控制来管理。
选型时可参考以下判断维度：
| 维度 | GitLab CI | Jenkins |
|---|---|---|
| 配置方式 | .gitlab-ci.yml 随代码版本化 | Jenkinsfile 或界面配置 |
| 与代码评审联动 | 原生MR触发，体验好 | 需Webhook插件 |
| 异构执行机管理 | Runner标签，能力较弱 | Agent标签、节点亲和强 |
| 长任务与并发控制 | 一般 | 成熟（throttle、lock） |
| 插件生态 | 够用 | 极丰富（高通/Android相关多） |
推荐落地策略：轻量任务（代码静态检查、单元测试、提交门禁）放GitLab CI；重量任务（全量编译、镜像打包、刷机验证）放Jenkins，由GitLab的Pipeline在通过门禁后触发Jenkins Job。
二、编译服务器资源规划
座舱Android+高通平台的编译是典型的“吃内存、吃IO、吃CPU”任务。规划时先明确三类资源：
- CPU：编译并行度由
-j控制，经验值是物理核数的1～1.5倍。若单机64核，建议-j64起步，观察负载再调整。 - 内存：Android全量编译峰值内存约为每并行任务1.5～2GB。64并行任务建议至少128GB，推荐256GB，否则易触发OOM Killer导致编译中断。
- 磁盘：源码+out目录+ccache，单套环境建议预留1.5～2TB NVMe SSD。机械盘会让编译时间成倍增加。
一个可参考的示例配置（属于合理假设，非实测）：
编译节点规格（示例）
CPU：AMD EPYC 64C / 128T
内存：256GB DDR4
系统盘：480GB SSD
数据盘：2TB NVMe（源码 + out + ccache）
网络：10GbE（拉取代码与上传镜像）
若团队规模较大，建议按“一台高配编译机 + 多台中配验证机”的方式规划，编译机专职跑全量构建，验证机跑增量编译与刷机测试，避免资源争抢。
三、Docker容器化构建环境
容器化的价值在于把“编译环境”变成可版本化的镜像，解决“换台机器就编不过”的经典问题。座舱CI的Docker镜像通常需要包含：
- Ubuntu 20.04/22.04 基础系统
- Android编译依赖（openjdk、python、git、repo、ccache等）
- 高通工具链（QCOM编译脚本、签名工具、打包工具）
- 与宿主机一致的UID/GID，避免产物权限错乱
镜像构建示例（节选）：
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
openjdk-11-jdk python3 git curl ccache \
&& rm -rf /var/lib/apt/lists/*
# 挂载高通工具链目录，避免镜像过大
VOLUME /opt/qcom-tools
WORKDIR /workspace
运行时通过 -v 挂载源码目录、ccache目录和高通工具链目录，既保证环境一致，又避免镜像臃肿。注意：高通工具链常涉及License，不要把License文件打进镜像，应通过挂载或环境变量注入。
四、与高通工具链集成
高通座舱平台的构建通常不是简单的 make，而是通过高通提供的脚本（如 build.sh、qcom_build.py 等）驱动。集成要点：
- 工具链路径固定：在容器内统一挂载到
/opt/qcom-tools，脚本中引用该路径，避免硬编码。 - License服务器可达：编译前先验证License服务连通性，失败则快速失败，不要等到编译中途才报错。
- 签名与打包分离：编译产物与签名密钥分离管理，签名步骤单独作为流水线阶段，便于权限控制。
- 产物归档：编译完成后自动归档镜像、符号表、编译日志，供后续刷机与问题定位。
下面这张图展示了从代码提交到镜像产出的完整信号与数据流，重点体现GitLab、Jenkins、编译节点、Docker容器与高通工具链之间的连接关系：
五、流水线阶段与关键判断
一条可落地的座舱CI流水线通常包含以下阶段，每个阶段都有明确的通过条件：
- 代码拉取：repo sync 成功，无冲突。
- 环境校验：容器启动正常，高通工具链路径可访问，License服务连通。
- 编译：全量或增量编译无error，warning数量在阈值内。
- 打包与签名：生成可刷写镜像，签名校验通过。
- 归档与通知：产物上传，结果回传GitLab，失败时附带日志片段。
最后，环境搭建完成后要用一次“从提交到镜像产出”的端到端演练来验证：提交一个空改动，观察流水线是否按预期触发、编译是否成功、产物是否归档、失败时是否能收到带日志的通知。只有这条链路跑通，后续的自动化测试、刷机验证、版本发布才有稳定的基础。