smart
67837df8d0
- 新增全套考试卷、评估卷、参考答案与考试培训包模板 - 修正slidev培训课件：调整模块标题、链路图缩放，替换工单示例为通用业务对象 - 修正课堂红线表述为证据红线，将小组作业调整为个人作业要求 - 新增权限、状态流转、审计日志、看板指标四类可复用业务规则块 - 整理AI工程技能交付包，迁移旧资产至客户专属交付包并统一术语 - 新增考试输出模板与TRAE使用记录文档
13 KiB
13 KiB
模块 4：CI 失败日志分析
CI 失败时，首先要判断失败来自代码、配置、依赖还是运行环境。
TRAE 可提取日志中的直接错误、关联改动和缺失证据；修复前仍要先确认失败来源。
代码
测试
配置
依赖
环境
先按失败来源分类
| 失败来源 | 常见信号 | 首先核对的材料 | 处理边界 |
|---|---|---|---|
| 代码与类型 | 编译、lint、类型报错指向具体文件 | diff、调用方、类型定义 | 只修改能解释错误的实现 |
| 测试断言 | 预期与实际结果不同 | 测试用例、业务规则、测试数据 | 不能只为通过而改断言 |
| 构建配置 | 脚本、工作流、环境变量缺失 | package/pom、workflow、项目规则 | 先确认配置是否属于本次改动 |
| 依赖解析 | 版本冲突、锁文件不一致、制品缺失 | lockfile、依赖树、仓库配置 | 区分项目依赖与制品服务异常 |
| Runner 与环境 | 权限、磁盘、网络、系统工具失败 | Runner 日志、环境配置、重试结果 | 不把环境故障归因到源码 |
分类不是为了快速贴标签，而是为了确定下一份该看的证据。
日志必须和 diff 一起读
| 日志现象 | 与 diff 的关系 | 正确结论 |
|---|---|---|
| 新增类型错误指向本次修改文件 | 直接命中新增或改动行 | 优先检查该改动与接口契约 |
| 测试失败在相邻模块，diff 未触及该模块 | 关联尚未建立 | 标记待确认，不把失败直接归因于本次改动 |
| 依赖下载失败，代码尚未进入编译 | 没有代码执行证据 | 按环境或依赖问题排查 |
| 同一失败在未改动分支也可复现 | 与本次 diff 无关 | 记录为基线问题或外部问题 |
日志给出直接错误
diff 说明影响范围
两者共同支持根因
代码修复与环境处置要分开
| 场景 | 代码侧动作 | 环境侧动作 | 不应做的事 |
|---|---|---|---|
| 类型或编译失败 | 修正实现、类型或调用契约 | 保持环境不变 | 顺手升级无关依赖 |
| 测试预期冲突 | 复核业务规则和测试数据 | 保留失败记录 | 只改断言让流水线通过 |
| 依赖解析失败 | 核对锁文件与版本声明 | 核对制品源、缓存和网络 | 修改业务逻辑 |
| Runner 权限或资源不足 | 不改项目源码 | 调整 Runner 或重试并留存结果 | 误报为代码缺陷 |
修复范围必须和失败来源一致；CI 通过也不应掩盖未验证的业务风险。
公务用车模块：已执行的定向测试门禁
mvn -pl jeecg-boot-module/jeecg-module-officialvehicle -am \
-DskipTests=false \
-Dtest=OfficialVehicleDispatchServiceImplTest \
-Dsurefire.failIfNoSpecifiedTests=false test
| 项目事实 | 该命令支持的结论 | 不能外推的结论 |
|---|---|---|
| 公务用车模块启用了 Maven Surefire 测试 | 模块依赖与指定 Service 用例能够被执行 | 接口、数据库、浏览器与审计链路已验证 |
| 用例传入全空白取消原因 | cancel 会在状态写入前拒绝空白原因 |
非空正常取消路径已经回归 |
2026-08-06 记录为 BUILD SUCCESS，1 项用例零失败 |
本次定向 Service 验证通过 | 全模块或生产可发布 |
可执行命令、实际结果和结论边界一起保存，才构成一项可复核的质量门禁证据。
真实失败案例：Maven 本地仓库无写入权限
[WARNING] Failed to write tracking file
$HOME/.m2/repository/.../resolver-status.properties
[ERROR] java.io.FileNotFoundException
(Operation not permitted)
[ERROR] BUILD FAILURE
| 判断项 | 本次结论 |
|---|---|
| 首个直接错误 | Maven 更新本地仓库跟踪文件时被系统拒绝 |
| 失败来源 | 本地环境 / 文件权限 |
| 与业务 diff 的关联 | 未建立源码关联证据 |
| 正确处置 | 恢复 Maven 仓库写入条件，保留日志后重跑 |
| 不应做的事 | 修改派车 Service、测试断言或业务状态逻辑 |
构建失败发生在依赖元数据写入阶段时，不能据此推断公务用车业务代码存在缺陷。
CI 分析任务上下文契约
请分析以下 CI 失败日志。
输入材料：CI 日志、相关 diff、package/pom/workflow 配置、锁文件、项目 rules。
请输出：
1. 首个失败阶段与原始错误；2. 失败来源分类；
3. 与 diff 的关联证据；4. 有依据的根因判断；
5. 需要查看的文件或环境信息；6. 候选处置方案；7. 验证命令；
8. 是否适合沉淀为规则或检查清单。
要求：先解释失败原因，再给方案；不能只根据最后一行日志下结论；
区分代码修复与环境处置；证据不足时标记待确认。
CI 修复记录
| 字段 | 内容 |
|---|---|
| 失败阶段 | lint / typecheck / test / build / dependency / environment |
| 原始错误 | 日志中的直接报错，不改写 |
| 失败来源 | 代码、测试、配置、依赖、Runner 或外部服务 |
| diff 关联 | 命中改动 / 无关联证据 / 待确认 |
| 根因 | 支持判断的日志、配置或代码证据 |
| 处置范围 | 代码修复或环境处置，涉及哪些位置 |
| 验证命令 | 本地或 CI 重新执行命令 |
| 结果 | 通过 / 未通过 / 待确认 |
| 资产沉淀 | rule / checklist / 任务上下文契约 / example / 不沉淀 |
CI 质量门禁分别覆盖什么？
| 门禁 | 作用 | 不能替代什么 |
|---|---|---|
| lint | 保证基础格式和规范 | 业务规则审查 |
| typecheck | 提前发现接口和类型不匹配 | 运行时行为验证 |
| unit test | 保护核心逻辑 | 完整集成链路 |
| coverage | 发现测试覆盖缺口 | 测试质量判断 |
| manual checklist | 覆盖权限、审计、状态和页面验收 | 可重复的自动化验证 |
质量门禁不是越多越好，而是每道门禁都要清楚自己覆盖和不覆盖什么。
一条 CI 结论应当写清什么？
| 信息 | 说明 |
|---|---|
| 失败阶段 | lint、类型检查、测试、构建、依赖或环境 |
| 原始错误 | 保留日志中的直接报错，不提前改写 |
| diff 关联 | 说明是否命中本次改动及依据 |
| 根因判断 | 说明对应的配置、代码或环境依据 |
| 处置范围 | 只指出确实需要调整的位置 |
| 验证方式 | 使用可重复的命令或 CI 结果确认 |
| 结论边界 | 证据不足时明确标记待确认 |
先区分直接错误、失败来源和根因，再决定是否修改代码。