技术深度解析
`actions/download-artifact` 是一个基于 Node.js 的 GitHub Action，用于从 GitHub 的内部 blob 存储中检索工作流工件，并将其提供给当前作业的文件系统。其架构简单直接，但针对可靠性和速度进行了优化。
核心架构：
- Node.js 运行时： 该动作在 GitHub 托管运行器的 Node.js 环境（当前为 Node 20）中运行。它使用 `@actions/artifact` 包处理所有存储交互。
- Blob 存储集成： 工件存储在 GitHub 管理的 blob 存储中（考虑到 GitHub 归微软所有，很可能使用 Azure Blob Storage）。该动作通过运行器内置的令牌进行身份验证，并使用具有短过期窗口的签名 URL 下载文件。
- 解压逻辑： 上传的工件由 `upload-artifact` 自动压缩为 `.zip` 文件。除非设置了 `--no-decompress` 标志，否则下载动作会自动解压。这由底层的 `adm-zip` 库处理。
- 模式匹配： `name` 输入支持精确名称或 glob 模式（例如 `test-results-*`）。这是通过 `minimatch` 对存储的工件名称进行模式匹配实现的。
关键输入和行为：
| 输入 | 类型 | 默认值 | 描述 |
|---|---|---|---|
| `name` | string | `artifact` | 要下载的工件名称或 glob 模式 |
| `path` | string | `${{ github.workspace }}` | 目标目录 |
| `repository` | string | `${{ github.repository }}` | 源仓库（支持跨仓库下载） |
| `run-id` | number | 当前运行 | 要从中下载的特定工作流运行 ID |
| `github-token` | string | `${{ github.token }}` | 用于身份验证的令牌 |
数据要点： 该表显示 download-artifact 高度可配置，支持跨仓库和跨运行下载。这种灵活性对于复杂工作流（如单体仓库构建）至关重要，因为工件需要在多个仓库之间共享。
性能考量：
- 延迟： 下载通常很快（小工件亚秒级，大工件几秒），因为工件存储在与运行器相同的 Azure 区域。
- 大小限制： 免费层仓库每次运行的总工件存储限制为 500 MB。付费计划每次运行可达 10 GB。单个工件最大可达 4 GB。
- 保留期： 工件默认在 90 天后过期（可按仓库配置）。这与缓存不同，缓存的 TTL 为 7 天。
与替代方案的对比：
| 特性 | download-artifact | actions/cache | 外部存储（S3、GCS） |
|---|---|---|---|
| 设置复杂度 | 零（内置） | 低（需要缓存键） | 高（需要 SDK、凭证） |
| 跨作业共享 | 是 | 是 | 是 |
| 跨仓库访问 | 是（需要令牌） | 否 | 是 |
| 保留期 | 90 天（默认） | 7 天 | 无限制（可配置） |
| 大小限制 | 每个工件 4 GB | 每个缓存 10 GB | 无限制 |
| 成本 | 免费（在配额内） | 免费 | 按存储/传输的 GB 付费 |
数据要点： download-artifact 在 GitHub 生态系统中以简单性和零成本取胜，但外部存储为大规模或长期工件保留提供了更多灵活性。对于大多数 CI/CD 管道，内置解决方案已足够。
关键参与者和案例研究
虽然 `actions/download-artifact` 是 GitHub 维护的动作，但其生态系统涉及多个关键参与者和实际实现。
GitHub（微软）： 作为维护者，GitHub 确保向后兼容性和性能。该动作是 `actions` 组织的一部分，该组织还维护 `upload-artifact`、`checkout` 和 `cache`。GitHub 的策略是提供无缝集成的体验，减少对第三方工具的需求。
案例研究：大型单体仓库构建（例如 Google 基于 Bazel 的工作流）
- 场景： 一个包含数百个微服务的单体仓库。每个服务在单独的作业中构建，生成 Docker 镜像作为工件。
- 实现： 构建作业使用 `upload-artifact` 存储镜像 tarball。后续的部署作业使用 `download-artifact` 配合 glob 模式获取所有镜像，并将其推送到注册表。
- 结果： 构建时间减少了 40%，因为工件在作业间重用，无需重新构建。
案例研究：测试报告聚合（例如 Jest + Playwright）
- 场景： CI 管道在并行作业中运行单元测试、集成测试和端到端测试。
- 实现： 每个测试作业将其 JUnit XML 报告作为工件上传。最终的 `report` 作业使用 `download-artifact` 配合 `test-results-*` 模式收集所有报告，然后通过自定义脚本将其合并为单个 HTML 报告。
- 结果： 开发人员无需手动聚合即可获得统一的测试仪表板。
与第三方替代方案的对比：
| 解决方案 | 维护者 | 关键特性 | 局限性 |
|---|---|---|---|
| actions/download-artifact | GitHub | 原生集成、零配置、跨仓库支持 | 大小和保留期限制 |
| actions/cache | GitHub | 快速、适合依赖缓存 | 仅限同一仓库、7 天 TTL |
| 外部存储（S3、GCS） | 第三方 | 无限制存储、自定义保留策略 | 设置复杂、需要凭证管理 |