Haiku 云端构建跑道

为什么是现在

Haiku R1/beta6 于 8 月 26 日发布，跨平台项目维护者因此更可能临时补做兼容验证。^S1 截至 8 月 31 日 00:33 UTC，相关 Hacker News 帖位列第 6，记录为 240 points、74 comments；关注到来时，没有 Haiku 机器的人更容易卡在重复构建与启动检查上。

核心用户是维护 CMake 或 Meson 桌面项目的人。beta6 发布后，他们收到兼容请求，或准备在发布说明中补上 Haiku。此时改动通常不大，却缺少可反复运行的 Haiku 机器。一次本地试跑不足以守住后续提交，他们需要把兼容检查放进拉取请求流程。

用 GitHub App 接收拉取请求事件，并通过 Checks API 回写排队、通过和失败状态。^S3 执行层先复用 QEMU 的 x86-64 beta6 镜像，代码通过 SSH 与 rsync 注入。首版仅解析 CMake、Meson 的命令阶段，不尝试理解任意构建系统。启动后调用 Haiku 自带的 `hey` 操作可脚本化界面，再用 `screenshot` 留存画面。失败分析按命令边界对齐不同平台日志，先定位最早的非零退出或缺包提示。配方草稿只填能从仓库和日志确认的字段，其余留空。HaikuPorts 对文件名、字段顺序和行宽已有明确规范，可据此做静态校验。^S4

第一批用户可从近期给项目补 Haiku 支持的 GitHub 提交者中寻找。针对公开仓库提交一份只增加 Haiku 检查的拉取请求，让报告本身成为演示。再到 HaikuPorts 的待处理移植和失败构建中，挑能稳定复现的案例发布诊断链接。获客内容应展示一次真实失败如何缩短到首个分歧命令，而不是泛讲跨平台 CI。

cross-platform-actions/actionGoogle

它已把 Haiku 虚拟机接入 GitHub Actions，并通过 QEMU 启动系统。代码与命令可经 SSH、rsync 进入虚拟机执行，当前文档也已列出 R1/beta6。^S2 对只需编译和命令行测试的项目，这条路径更轻，维护者还能直接沿用现有工作流。缺口在于它提供的是通用执行环境，不负责定义桌面应用的冒烟步骤。窗口是否打开、菜单是否可用、文件能否经界面读写，仍要项目自己写脚本和判断条件。它也不会主动对齐 Linux、BSD 与 Haiku 日志，找出首个分歧命令。依赖失败后，维护者仍需自行追踪源码引用，再按 HaikuPorts 规则编写配方。所选产品必须靠这些诊断与制品能力形成差异，单纯提供 beta6 虚拟机很容易被替代。

自建 QEMU 镜像与 CI 节点Google

另一种惯用做法是维护者自己保存 Haiku 的 QEMU 镜像，再接入现有 CI 或自托管执行节点。这样能完全控制镜像、工具链和缓存，也适合已有 Haiku 维护者处理特殊依赖。GitHub App 可通过 webhook 和 Checks API 创建、更新及重跑检查，因此状态回写本身不是稀缺能力。^S3 真正的缺口是镜像升级、并发调度、失败清理和远程访问都由项目承担。桌面程序还需要处理图形会话、截图和操作脚本，任务挂起时也要回收虚拟机。多个仓库各自维护后，依赖版本与诊断格式容易分散。小项目通常不会为了偶尔一次兼容修复长期养这套设施。产品若不能显著减少镜像维护和失败定位时间，就难以说服已有自建流程的人迁移。

按 Haiku 虚拟机执行分钟收费，包含基础日志与短期产物保存。公开仓库可给少量免费额度，私有仓库购买月度分钟包。远程排查时段和更长镜像保留期作为附加项收费。

图形冒烟测试很容易产生误报。窗口启动较慢、菜单名称变化或焦点丢失，都可能把可用程序判成失败。维护者若连续收到无效红灯，会直接关闭这项检查。保留可远程访问的失败镜像还会增加隔离、密钥回收和资源清理负担。自动生成配方也可能误认间接依赖，提交低质量草稿反而增加 HaikuPorts 审核成本。不同项目的启动方式差异很大，预设步骤覆盖不足时，配置成本会重新落回用户身上。继续做之前，应先证明少量稳定动作能覆盖足够多的桌面项目。