3. 持续集成环境搭建

在 AUTOSAR 项目中，持续集成环境的核心任务不是“让流水线跑起来”，而是让 ETAS 工具链在无人值守的构建代理上稳定、可复现地完成代码生成、编译与校验。与普通软件项目不同，ETAS 工具链（如 ISOLAR-AB、RTA-CAR、EB tresos 等）通常依赖图形化许可证、特定版本的 Java 运行时、Windows 环境变量以及本地安装目录，这些因素决定了 CI 集成方案必须围绕“代理节点 + 许可证服务 + 版本锁定”三件事展开。

一、CI 平台与 ETAS 工具链的集成方式

Jenkins 与 GitLab CI 都能驱动 ETAS 工具链，但集成路径不同。Jenkins 通常采用“主节点调度 + 专用构建代理”的模式，代理上预装 ETAS 工具链，通过批处理或 PowerShell 脚本调用工具命令行；GitLab CI 则通过 .gitlab-ci.yml 中的 tags 将作业路由到已注册的 Runner，Runner 同样需要预装工具链。两者共同点是：工具链不安装在 CI 服务器主节点，而安装在可水平扩展的构建代理上，主节点只负责调度与结果收集。

ETAS 工具链的调用一般有两种入口：一是工具自带的命令行接口（CLI），例如 ISOLAR-AB 的工程导出与代码生成命令；二是通过 ETAS 提供的自动化脚本或 API 封装。实际集成时，推荐优先使用 CLI，因为 CLI 更容易在无图形界面的代理上执行，也便于把退出码作为流水线成败判断依据。下面是一个 Jenkins 流水线中调用 ETAS 工具链生成代码的示例片段（示例参数，非实测结果）：

pipeline {
  agent { label 'etas-win-agent' }
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Generate') {
      steps {
        bat '''
          set ETAS_HOME=C:\\ETAS\\ISOLAR-AB_10.5
          "%ETAS_HOME%\\bin\\isolar-cli.bat" ^
            -project "%WORKSPACE%\\cfg\\EcuExtract.arxml" ^
            -out "%WORKSPACE%\\gen" ^
            -license 27000@lic-server.corp.local
        '''
      }
    }
    stage('Build') {
      steps { bat 'call build.bat' }
    }
  }
}

GitLab CI 的等价写法是把上述命令放入 script，并用 tags: [etas-win] 指定 Runner。无论哪种平台，都建议把工具链路径、许可证服务器地址、工程文件路径抽成变量，避免硬编码在脚本里。

二、构建代理配置的关键点

构建代理是 ETAS 工具链真正运行的地方，配置质量直接决定流水线是否稳定。建议从以下四个层面固化代理环境：

• 操作系统与运行时：ETAS 工具链多数版本对 Windows 有强依赖，代理应使用与开发人员一致的 Windows 版本，并预装匹配的 JDK（例如 ISOLAR-AB 10.5 常要求 JDK 11）。JAVA_HOME 必须指向该 JDK，而不是系统默认版本。
• 工具链安装路径：统一安装到固定目录（如 C:\ETAS\ISOLAR-AB_10.5），并把 ETAS_HOME 写入系统环境变量。代理镜像一旦固化，所有作业都使用同一路径，避免脚本因路径差异失败。
• 代理标签与资源隔离：在 Jenkins 中为代理打上 etas-win-agent 标签，在 GitLab 中为 Runner 打上 etas-win 标签，确保只有需要 ETAS 工具链的作业才会被调度到这些代理上，避免普通编译作业占用许可证席位。
• 工作空间清理：ETAS 工具在生成代码时会写入大量中间文件，若工作空间不清理，容易因残留文件导致生成结果不一致。建议在流水线开始处执行 cleanWs()（Jenkins）或 git clean -fdx（GitLab），保证每次构建从干净状态开始。

三、许可证管理：从“能跑”到“稳定跑”

ETAS 工具链通常使用 FlexNet 浮动许可证，代理通过 27000@lic-server.corp.local 这样的地址向许可证服务器借证。CI 环境中最常见的问题是并发作业数超过许可证席位，导致部分作业在借证阶段阻塞甚至超时失败。处理方式有三条：

1. 限制并发：在 Jenkins 中通过 disableConcurrentBuilds() 或代理执行器数量控制并发；在 GitLab 中通过 Runner 的 concurrent 参数限制。并发上限应小于等于许可证席位数量。
2. 设置借证超时：在工具命令行中显式指定许可证等待超时（如 120 秒），避免作业无限期挂起。超时后应让作业快速失败并输出明确日志，便于定位是许可证不足还是工具本身出错。
3. 许可证使用监控：定期检查许可证服务器的借证日志，统计高峰时段的席位占用率。若长期接近满载，应申请增补席位或把非必要作业调整到低峰时段执行。

四、依赖管理：让构建可复现

AUTOSAR 项目的依赖比普通软件更复杂，除了编译器、构建工具，还包括 BSW 包、MCAL 驱动、ARXML 模板以及 ETAS 工具链自身的补丁版本。依赖管理的目标是：同一提交在任何时间、任何代理上都能得到一致的构建结果。实现手段包括：

• 版本清单文件：在仓库根目录维护一份 toolchain.lock，记录工具链版本、BSW 包版本、编译器版本。流水线启动时先校验代理上的实际版本是否与清单一致，不一致则直接失败并提示。
• 制品库统一存放：把 BSW 包、MCAL 驱动、第三方库上传到 Nexus 或 Artifactory，代理通过制品库拉取，而不是从开发人员本地目录复制。这样能避免“某台代理上有、另一台没有”的问题。
• 缓存加速：对不常变化的依赖（如编译器、BSW 包）在代理本地做缓存，流水线只拉取变更部分。缓存目录应纳入代理镜像管理，避免缓存污染导致构建结果漂移。

五、一个可参考的流水线检查清单

下表汇总了本节涉及的关键配置项与判断依据，可作为搭建或排查 CI 环境时的对照表（示例字段，按项目实际情况调整）：

总体而言，Jenkins/GitLab CI 与 ETAS 工具链的集成，难点不在流水线语法，而在代理环境的一致性、许可证的并发控制和依赖的版本锁定。把这三件事固化到代理镜像和流水线模板中，后续新增项目时只需复用模板，就能显著降低环境搭建的重复成本。