Asuswrt-Merlin.ng项目构建过程中遇到的Artifact上传问题分析与解决方案

问题背景

在构建Asuswrt-Merlin.ng项目针对rtl8152网卡友好的固件版本时，开发者在GitHub Actions工作流中遇到了构建失败的问题。具体表现为使用actions/upload-artifact的不同版本时出现了不同的行为：

1. 使用v2版本时构建失败
2. 使用v4版本时出现权限错误
3. 使用v3.1.3版本时构建成功

技术分析

GitHub Actions中的Artifact上传机制

GitHub Actions中的upload-artifact是一个核心操作，用于在工作流运行期间将文件或目录保存为构建产物(artifact)。这些产物可以跨作业传递，或者在构建完成后下载。

版本差异分析

1. v2版本：这是较早期的实现，随着GitHub Actions平台的更新，v2版本已经逐渐变得不兼容新的运行环境，特别是在权限管理和文件处理方面。

2. v3.1.3版本：这是一个稳定的中间版本，在v2和v4之间提供了良好的兼容性，解决了v2的一些问题，同时避免了v4引入的新权限模型带来的问题。

3. v4版本：这是最新的主要版本，引入了更严格的权限控制和安全性改进。错误信息"EACCES: permission denied"表明v4版本使用了更严格的权限模型，而工作流中的某些操作没有获得足够的权限。

解决方案

针对这个问题，最直接的解决方案是使用v3.1.3版本的upload-artifact操作。这个版本既解决了v2版本的兼容性问题，又避免了v4版本的权限问题。

在GitHub Actions工作流文件中，应将：

uses: actions/upload-artifact@v2

修改为：

uses: actions/upload-artifact@v3.1.3

深入探讨

为什么v4版本会失败

v4版本引入了一个更安全的运行环境，特别是在容器化的执行环境中。错误信息中提到的"/__w/_temp/_runner_file_commands"路径是GitHub Actions内部使用的临时目录，v4版本可能尝试在这个目录中创建或修改文件时遇到了权限限制。

长期解决方案

虽然v3.1.3版本可以暂时解决问题，但从长远来看，开发者应该：

1. 检查工作流中其他步骤是否使用了过时的Actions
2. 逐步测试并迁移到v4版本，确保所有文件操作都有适当的权限
3. 考虑使用更精细的路径指定，避免依赖临时目录

最佳实践建议

1. 版本锁定：在使用第三方Actions时，最好锁定到特定的小版本(如v3.1.3)，而不是使用主版本(如v3)，以确保构建的稳定性。

2. 权限配置：如果必须使用v4版本，可以尝试在工作流开始时添加适当的权限声明：

   permissions:
     contents: write
   

3. 逐步升级：对于复杂的构建系统，建议逐步升级Actions版本，并在每次更改后进行全面测试。

结论

在Asuswrt-Merlin.ng项目的构建过程中，选择合适的GitHub Actions版本对于构建成功至关重要。针对当前情况，使用upload-artifact@v3.1.3版本是最稳妥的解决方案，既保证了功能的正常使用，又避免了兼容性问题。开发者应保持对Actions更新的关注，并在适当的时候进行全面的工作流升级测试。