将GitHub CI迁移至Hugging Face Jobs

GitHub Actions 的免费 CI 额度对于很多开源项目来说已经捉襟见肘，尤其是当项目需要 GPU 来跑测试时。现在，Hugging Face 提供了一个新方案：把 CI 任务迁移到 Hugging Face Jobs 上运行，不仅能获得更快的 CPU 执行速度，还能按需调用 GPU 硬件，而且整个过程对 GitHub 来说就像是一个自托管 Runner，无需改变现有的工作流习惯。 这个方案的诞生源于一个实际痛点。AI 项目 Trackio 在开发过程中发现，GitHub 自带的 Runner 不仅速度慢、偶尔宕机，最关键的是无法提供 GPU 环境。为了让单元测试和前端检查跑在 CPU 上，同时让需要 CUDA 硬件的测试也能顺利执行，团队决定不走“自建 Runner”的老路，而是用 Hugging Face Jobs 作为底层计算资源。结果是：CPU 任务的 CI 时间缩短了约 30%，并且成功开启了全新的 GPU 测试套件。整个架构的核心是一个名为 `huggingface/jobs-actions` 的桥接工具，它把 GitHub Actions 的 Job 变成一个在 Hugging Face 基础设施上运行的临时自托管 Runner。 具体来说，当你在 GitHub 上发起一个 Pull Request 时，工作流会触发一个带有特定标签（如 `hf-jobs-cpu-upgrade` 或 `hf-jobs-t4-small`）的 Job。由于 GitHub 上没有匹配的 Runner，它会等待。此时，一个部署在 Hugging Face Space 上的“调度器”会通过 GitHub App 接收 webhook 通知，验证标签后，生成一个一次性的 Runner 注册令牌，然后在 Hugging Face Jobs 上启动一个对应硬件规格的容器。这个容器启动后，会立即向 GitHub 注册为一个临时的自托管 Runner，执行完任务后自动销毁。从 GitHub 的角度看，这只是一个普通的自托管 Runner；从 Hugging Face 的角度看，这只是一个启动容器来执行工作流步骤的 Job。 要复现这个方案，第一步是复制调度器 Space。你需要访问 `huggingface/jobs-actions-dispatcher` 这个 Space 并点击“Duplicate this Space”。在设置中，Owner 选择你的 Hugging Face 用户名或组织，Name 可以保持默认的 `jobs-actions-dispatcher`，硬件选择 `cpu-upgrade` 即可。这个 Space 的作用是接收 GitHub 的 webhook 事件并启动 Hugging Face Jobs，所以它必须在你的命名空间下，并且拥有写入权限。完成这一步后，你会得到一个 Space 的 URL，这个 URL 就是稍后配置 GitHub App 时需要填入的 webhook 地址。