Apache Pulsar CI系统升级GitHub Actions Artifact客户端的必要性

背景介绍

Apache Pulsar作为一款高性能的分布式消息系统，其持续集成(CI)流程对于保证代码质量至关重要。当前Pulsar项目使用GitHub Actions作为CI平台，并通过自定义的Artifact客户端来管理构建过程中产生的各类文件，包括Docker镜像和二进制构建结果等中间产物。

技术挑战

GitHub官方已宣布将于2024年11月30日停止支持v1、v2和v3版本的Artifact Actions。这意味着所有仍在使用旧版本API的工作流将在此日期后失效。Pulsar CI系统中目前使用的自定义Artifact客户端正是基于这些即将被弃用的版本构建的。

现有实现分析

Pulsar CI系统采用了一种创新的解决方案——自定义的"GitHub Actions Artifact客户端"。这个客户端不是直接使用标准的GitHub Action，而是基于GitHub提供的JavaScript库自行构建的，具有以下特点：

1. 可以在shell脚本中直接调用
2. 支持上传和下载任意文件
3. 主要用于缓存工作流运行期间的构建产物

具体应用场景包括：

• 构建Docker镜像后缓存，供后续集成测试和系统测试复用
• 共享二进制构建结果，避免重复构建

升级方案

升级工作主要涉及将自定义客户端从v3迁移到v4版本的GitHub Actions Artifact API。虽然新版本的API模型有所变化，但技术上是可行的。升级后的客户端需要：

1. 使用v4版本的JavaScript客户端库
2. 适配新的API调用方式
3. 保持现有功能不变

升级效果

实际升级后观察到以下改进：

1. 上传性能显著提升：Docker镜像上传速度达到186MiB/s
2. 恢复操作同样高效：包括流式传输到docker load的整个过程都更加快速
3. 整体CI流程更加稳定可靠

技术意义

这次升级不仅解决了API弃用带来的兼容性问题，还意外获得了性能提升。这体现了：

1. 及时跟进基础设施更新的重要性
2. 自定义工具链可以带来更灵活的CI/CD流程
3. GitHub Actions生态系统的持续进化

总结

Apache Pulsar项目通过及时升级Artifact客户端，不仅规避了即将到来的服务中断风险，还提升了CI系统的整体性能。这一案例展示了开源项目如何通过主动技术升级来保持系统的稳定性和先进性。对于其他依赖GitHub Actions的项目，这也是一次有价值的参考。