TeslaMate项目中的GitHub Actions上传构件升级实践

背景介绍

在持续集成/持续部署(CI/CD)流程中，GitHub Actions是一个广泛使用的自动化工具。TeslaMate项目作为一款开源的Tesla车辆数据记录器，其CI流程中也大量使用了GitHub Actions来自动化构建和测试过程。

问题发现

在近期的一次CI运行中，系统提示Node.js 16版本的actions已被弃用，特别是actions/upload-artifact@v3这个上传构件的action需要升级到使用Node.js 20的版本。这促使团队需要将上传构件的action从v3升级到v4版本。

升级挑战

上传构件action从v3升级到v4带来了一些破坏性变更，主要包括：

1. 构件名称冲突处理方式变化
2. 路径参数使用方式变更
3. 工作目录设置要求更严格

解决方案探索

团队首先尝试直接升级到v4版本，但立即遇到了构件名称冲突的问题。这是因为v4版本对同名构件的处理策略有所改变，不再自动覆盖已有构件。

通过深入研究，团队发现需要重构构件命名策略，确保每个构件的名称在运行环境中是唯一的。具体实现方式包括：

1. 在构件名称中加入运行环境标识
2. 为不同运行环境设置不同的构件名称前缀
3. 确保并行任务不会产生名称冲突

实施过程

升级过程并非一帆风顺，团队遇到了几个关键问题：

1. 构件合并失败：在PR构建中，合并下载构件时出现路径问题
2. 环境变量解析异常：矩阵变量在某些情况下未被正确解析
3. 工作目录设置：v4版本要求更严格的工作目录设置

经过多次测试和调整，团队最终确定了以下最佳实践：

1. 在upload-artifact步骤前明确设置工作目录
2. 使用更精细的构件命名策略
3. 在下载构件时正确设置目标路径

经验总结

这次升级给团队带来了宝贵的经验：

1. GitHub Actions的版本升级需要充分测试，特别是涉及破坏性变更时
2. 构件命名策略在CI流程中至关重要，需要确保唯一性和可追溯性
3. 工作目录设置是许多action的关键前置条件
4. PR构建和主分支构建可能存在环境差异，需要分别验证

最终效果

经过多次迭代和测试，团队成功将upload-artifact action升级到v4版本，并解决了所有相关问题。新的CI流程运行稳定，能够正确处理构件上传和下载，为项目的持续集成提供了可靠保障。

这次升级不仅解决了Node.js版本过时的问题，还使TeslaMate项目的CI流程更加健壮和可靠，为未来的功能扩展奠定了良好基础。