Oppia项目中CI测试中"Artifact Not Found"问题的分析与解决

问题背景

在Oppia项目的持续集成(CI)测试过程中，开发团队发现了一个影响测试稳定性的问题。具体表现为在Acceptance测试阶段，系统无法找到预期的构建产物(build artifact)，导致测试流程中断。这个问题在多个PR的测试运行中都曾出现，对开发流程造成了一定影响。

问题现象

当开发者在GitHub Actions中运行测试时，特别是在重新运行测试时，系统会抛出"Artifact not found for name: build_files"的错误。错误信息表明系统无法下载名为"build_files"的构建产物，导致后续测试步骤无法继续执行。

问题分析

经过团队成员的深入调查，发现这个问题有以下几个关键特征：

1. 时间敏感性：该问题通常发生在首次测试运行超过一天后尝试重新运行测试时出现。这表明可能与GitHub Actions的artifact存储机制或过期策略有关。

2. 工作流依赖性：问题主要出现在"Download Build Files Artifact"步骤，这是测试流程中获取构建产物的关键环节。

3. 影响范围：虽然问题不会阻止首次测试运行，但会影响测试失败后的重试机制，特别是当开发者只选择重新运行失败的测试时。

临时解决方案

在问题完全修复前，团队发现了一个可行的临时解决方案：

1. 当遇到此问题时，不要仅重新运行失败的测试
2. 而是选择重新运行完整测试工作流中的所有测试
3. 这样可以确保系统重新生成所有必要的构建产物

根本原因与永久修复

经过进一步分析，团队确定了问题的根本原因：

1. GitHub Actions对构建产物有默认的保留期限
2. 当超过一定时间后重新运行测试时，原始构建产物可能已被清理
3. 仅重试失败测试的工作流没有重新生成构建产物的步骤

团队通过PR #21509实施了永久性修复方案，主要改进包括：

1. 优化了构建产物的生成和存储逻辑
2. 确保在测试重试时能够正确获取或重新生成所需的构建产物
3. 改进了工作流的容错机制

经验总结

这个案例为开发者提供了几个重要的经验教训：

1. CI/CD流程中的artifact管理需要考虑时间因素和清理策略
2. 测试重试机制应该具备自包含性，不依赖可能过期的中间产物
3. 对于关键构建步骤，应该设计适当的回退或重建机制

通过这次问题的解决，Oppia项目的CI流程变得更加健壮，减少了因环境因素导致的测试失败，提高了开发效率。