构建产物去哪了：认识GitHub Actions的存储

一次自动构建结束后，程序包和测试报告不一定会留在运行构建的机器上。为了让人之后还能下载它们，工作流可以把文件上传为构建产物，也就是artifact。

这些产物很方便：测试失败时可以查看报告，需要试用时也可以下载安装包。但构建运行得越频繁，保存的文件也越多。如果每次提交都上传完整安装包，存储增长可能比想象中快。

1. 构建产物保存了什么#

产物可以是一份安装包、一组测试报告，也可以是截图、日志或其他构建输出。工作流结束后，只要产物还在保留期内，就可以从对应的运行记录中下载。

同一次构建中的文件用途并不一样。安装包主要用于安装和试用，诊断报告则用于了解构建或测试发生了什么。给它们分别命名、分别上传，之后寻找和清理都会更容易。

产物不是上传后就应该永久保留。GitHub Actions可以为上传的产物设置保留天数，具体可用范围受仓库和组织设置影响。

设置保留期时，可以先看文件的实际用途。经常变化的临时安装包可能只需要短期保存，测试报告和诊断材料则可以根据排查需要采用不同的期限。重要版本应当有明确的长期保存位置，而不是只依赖一次临时构建。

自动化的目的，是让每次改动都能得到及时反馈。对于日常提交，运行检查、测试和构建通常很有价值；但构建成功并不意味着每次都需要把完整安装包上传。

一种安排是：日常提交照常执行测试和构建，只在需要试用时手动触发安装包上传。诊断报告可以单独保存，这样既能保留排错线索，也能减少大文件的重复积累。

具体采用哪种方式，要看项目是否依赖每次构建产物进行测试。多人协作或需要逐次追溯的项目，也许需要保留更多版本。

存储不足时，可以先列出产物的名称、大小和对应运行记录，再确认哪些文件仍有用途。一个压缩包里可能既有安装程序，也有测试报告；如果只按文件名判断，容易把仍需要的诊断材料一起删掉。

对于需要长期保留的材料，先下载并检查备份是否完整，再处理旧产物。清理后还应回看保留的文件和用量。存储账单通常按占用量和时间累计，删除后页面上的统计不一定立刻变化。

当构建频率、文件大小和保留时间都清楚以后，就能更容易判断哪些产物应该自动上传，哪些只需要按需生成。