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

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

2025-06-10 05:06:35作者:薛曦旖Francesca

背景介绍

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. 开源协作能快速推动技术问题解决

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

登录后查看全文

项目优选

收起
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
51
15
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
116
200
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
503
398
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
62
144
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
295
1.01 K
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
97
251
cherry-studiocherry-studio
🍒 Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端
TypeScript
381
37
MateChatMateChat
前端智能化场景解决方案UI库,轻松构建你的AI应用,我们将持续完善更新,欢迎你的使用与建议。 官网地址:https://matechat.gitcode.com
692
91
RuoYi-Cloud-Vue3RuoYi-Cloud-Vue3
🎉 基于Spring Boot、Spring Cloud & Alibaba、Vue3 & Vite、Element Plus的分布式前后端分离微服务架构权限管理系统
Vue
97
74
HarmonyOS-ExamplesHarmonyOS-Examples
本仓将收集和展示仓颉鸿蒙应用示例代码,欢迎大家投稿,在仓颉鸿蒙社区展现你的妙趣设计!
Cangjie
357
341