OSHI项目在FlyCI与GitHub Actions缓存机制差异分析

背景介绍

OSHI作为一个跨平台、跨架构的系统信息监控库，需要在多种操作系统和硬件架构上进行全面测试。近期项目在集成FlyCI的M1架构Runner时，发现了一个与Maven依赖缓存相关的性能问题。本文将深入分析该问题的技术本质及解决方案。

问题现象

在持续集成过程中，FlyCI Runner表现出以下异常特征：

1. 测试执行前阶段比GitHub原生Runner多耗时约1分钟
2. Maven依赖需要重复从中央仓库下载
3. 尽管缓存恢复步骤显示成功，但实际构建时无法命中本地仓库

通过对比日志发现，GitHub Runner能正确复用缓存依赖：

[INFO] Using cached依赖：-javaagent:/Users/runner/.m2/repository/org/jacoco/org.jacoco.agent/0.8.11/org.jacoco.agent-0.8.11-runtime.jar

而FlyCI Runner则显示完整下载过程：

[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/jacoco/org.jacoco.agent/0.8.11/org.jacoco.agent-0.8.11.pom
...
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/jacoco/org.jacoco.agent/0.8.11/org.jacoco.agent-0.8.11-runtime.jar

技术分析

缓存机制原理

GitHub Actions的缓存系统基于以下关键设计：

1. 采用相对路径存储（../../../.m2/repository/）
2. 默认假设缓存文件位于用户主目录（~/.m2）
3. 使用tar压缩包格式进行归档

根因定位

FlyCI Runner与GitHub Runner存在目录结构差异：

• GitHub Runner路径：/Users/runner/work/_temp/
• FlyCI Runner路径：/opt/actions-runner/_work/_temp/

当缓存恢复时，相对路径../../../.m2在不同基础路径下会解析到不同位置：

• GitHub Runner正确还原到：/Users/runner/.m2
• FlyCI Runner错误还原到：/opt/actions-runner/.m2

而Maven默认查找的是用户主目录下的.m2仓库，导致缓存失效。

解决方案验证

通过启用Maven调试模式（-X参数）确认：

1. FlyCI Runner确实将缓存恢复到非标准路径
2. Maven仍按标准路径查找依赖
3. 手动指定缓存路径可临时解决问题

最佳实践建议

对于需要在多平台Runner间共享缓存的项目：

1. 路径标准化

   • 确保所有Runner使用相同的用户主目录结构
   • 或显式配置Maven本地仓库路径

2. 缓存策略优化

   • 对不同Runner类型使用差异化缓存key
   • 考虑使用setup-java等专业action管理缓存

3. 监控机制

   • 添加缓存命中率检查步骤
   • 记录依赖下载耗时指标

后续进展

FlyCI团队在收到反馈后24小时内发布了新版本镜像，主要改进包括：

1. 标准化Runner安装路径到用户主目录
2. 确保与GitHub原生Runner的路径兼容性
3. 验证显示构建时间从原来的1分钟+降至40秒

经验总结

1. 跨平台CI/CD需特别注意文件系统路径差异
2. 缓存机制对构建性能影响显著（本例提升达50%）
3. 开源协作能快速推动技术问题解决

该案例展示了基础设施兼容性问题对构建效率的重要影响，也为其他需要多平台支持的开源项目提供了宝贵参考。