Digger项目中的GitHub Artifact下载失败问题分析与解决方案

问题背景

在Digger项目的使用过程中，用户报告了一个关于GitHub Artifact下载失败的问题。具体表现为：当配置使用GitHub作为tfplan文件存储目的地时，digger plan命令能够成功将计划文件附加到PR中，但随后的digger apply命令在执行时会失败，报错显示无法从GitHub下载之前存储的计划文件。

技术分析

问题现象

1. 成功场景：digger plan命令运行时，能够正确生成并以"plan-$PRNUMBER.zip"格式将计划文件上传至GitHub
2. 失败场景：digger apply命令执行时，会重新生成一个本地tfplan文件但不上传，随后尝试从GitHub下载计划文件时失败，返回400错误

底层机制

Digger的计划文件存储逻辑遵循以下流程：

1. 通过GitHub API的ListArtifacts方法列出仓库所有构件
2. 筛选出符合"plans-{prNumber}"模式的最新构件
3. 使用GitHub客户端的DownloadArtifact方法获取构件下载URL（302重定向）
4. 使用该URL实际下载构件到本地plans-{prNumber}.zip文件

错误根源

问题出现在第四步下载过程中，系统返回400错误。错误信息显示Azure Blob Storage认证格式不正确：

<?xml version="1.0" encoding="utf-8"?>
<Error>
  <Code>InvalidAuthenticationInfo</Code>
  <Message>Authentication information is not given in the correct format...
</Message>
</Error>

尽管下载URL包含SAS令牌且理论上应该是公开可访问的（有效期1分钟），但系统仍然无法完成认证。

解决方案

开发团队通过分析发现，问题出在GitHub返回的Azure Blob Storage URL处理逻辑上。修复方案主要涉及：

1. 正确处理GitHub API返回的302重定向
2. 优化下载流程中的认证处理机制
3. 确保下载请求的头部信息符合Azure Blob Storage的要求

技术启示

这个问题揭示了几个重要的技术点：

1. 跨平台认证：当服务（GitHub）依赖另一云平台（Azure）的基础设施时，认证流程可能变得复杂
2. 临时URL处理：对于有时效性的下载链接，客户端需要具备快速响应和处理能力
3. 错误处理：需要针对不同云服务提供商设计差异化的错误处理机制

最佳实践建议

对于使用类似架构的项目，建议：

1. 实现完善的日志记录机制，特别是在跨服务调用环节
2. 为临时性资源访问设计重试逻辑
3. 考虑添加本地缓存作为远程存储的备份方案
4. 对不同的存储后端实现统一的抽象接口，便于切换和维护

该问题的解决不仅修复了Digger的核心功能，也为处理类似云服务集成问题提供了有价值的参考案例。