Kuberay项目CI日志归档优化实践

在Kuberay项目的持续集成(CI)流程中，日志管理是一个重要的环节。本文将详细介绍如何将测试日志作为构建产物(Build Artifacts)上传到BuildKite平台的技术实现方案。

背景与需求

Kuberay项目最初使用GitHub Actions作为CI平台，测试失败时会自动将日志文件打包并上传为构建产物。随着项目发展，CI平台迁移到了BuildKite，需要实现类似的日志归档功能。

核心需求包括：

1. 仅在测试失败时上传日志
2. 收集指定目录下的所有.log文件
3. 将日志打包为zip格式
4. 上传到BuildKite的artifact存储系统

技术实现要点

日志收集路径

测试日志默认存储在环境变量KUBERAY_TEST_OUTPUT_DIR指定的目录下，需要递归收集该目录及其子目录中的所有.log文件。这种设计确保了无论测试用例如何组织日志文件结构，都能完整收集。

构建产物上传机制

BuildKite提供了专门的/artifact-mount目录作为构建产物的挂载点。任何写入该目录的文件都会在构建完成后自动上传到BuildKite的存储系统。这种机制比GitHub Actions的artifact上传API更为简单直接。

条件触发策略

日志上传应当遵循"失败时上传"的原则，这可以通过CI脚本的条件判断实现。典型的做法是在测试步骤后检查退出状态码，非零时执行日志收集和上传操作。

实现方案对比

与原先GitHub Actions的实现相比，BuildKite方案有以下特点：

1. 更简单的配置：无需复杂的API调用，只需将文件写入指定目录
2. 统一的存储格式：建议将所有日志打包为单个zip文件，便于下载和管理
3. 更好的集成性：BuildKite的artifact系统与构建界面深度集成，查看日志更加方便

最佳实践建议

1. 日志命名规范：建议在测试脚本中为日志文件添加时间戳和测试用例标识，便于问题定位
2. 日志清理：成功构建后应清理临时日志文件，避免占用过多磁盘空间
3. 日志大小限制：对于大型项目，应考虑设置日志文件大小上限或只上传错误相关的日志片段
4. 安全考虑：确保日志中不包含敏感信息，如密钥、凭证等

总结

通过实现BuildKite的日志归档功能，Kuberay项目获得了与之前GitHub Actions相当甚至更好的日志管理能力。这种优化不仅提升了开发者在CI失败时的调试效率，也为项目的长期维护提供了更好的可观测性支持。对于其他考虑迁移CI平台的项目，这种日志管理方案也值得借鉴。