Haiku Cloud Build Lane
After a cross-platform project receives a commit, it builds and launches automatically in a real Haiku beta6 image, returning the first point of divergence and a committable porting-recipe draft.
With Haiku R1/beta6 newly released, maintainers of cross-platform projects may be willing to add a quick compatibility pass, but often lack a dedicated machine and cannot rerun verification after every commit. Developers enable a check in a GitHub repository and select build commands, a launch method, and a few basic UI actions. As soon as a pull request appears, the job joins a queue for a real Haiku beta6 image.
After the build, the service launches the app in the image, runs smoke tests such as opening a window, reading and writing files, or clicking menus, and retains screenshots, terminal output, and dependency versions. Failure reports do more than paste a long log: they align build steps across Linux, BSD, and Haiku to identify the first command that diverges. If a package is missing, the report lists the source locations that call it, the required version, and available repository information, then generates a HaikuPorts recipe draft for the maintainer to complete.
Developers can write pass status back to the pull request and retain failed images for a limited period of remote debugging. The first release supports CMake and Meson, along with build and launch checks for common desktop applications, with the aim of making niche-platform support a routine CI checkbox. It does not automatically maintain a complete port for a project or promise to replace long-term compatibility testing with real users.
Why now
Haiku R1/beta6 was released on August 26, making cross-platform project maintainers more likely to add a compatibility check on short notice. S1 As of August 31 at 00:33 UTC, the related Hacker News post ranked sixth, with 240 points and 74 comments; while attention is arriving, people without a Haiku machine are more likely to get stuck on repeated build and launch checks.
Target user
The core user is a maintainer of a CMake- or Meson-based desktop project. After beta6 ships, they receive a compatibility request or want to add Haiku to their release notes. The change is usually small, but they lack a Haiku machine they can rerun reliably. A one-off local test cannot protect later commits, so they need compatibility checks in the pull-request workflow.
Minimal entry point
Use a GitHub App to receive pull-request events and write queued, passed, and failed statuses back through the Checks API. S3 The execution layer initially reuses a QEMU x86-64 beta6 image, injecting code through SSH and rsync. The first release parses only the command stages of CMake and Meson rather than attempting to understand arbitrary build systems. After launch, it uses Haiku’s built-in `hey` tool to script UI actions and `screenshot` to capture the display. Failure analysis aligns logs from different platforms at command boundaries, first locating the earliest nonzero exit or missing-package message. Recipe drafts fill only fields confirmed by the repository and logs; the rest remain blank. HaikuPorts has explicit conventions for filenames, field ordering, and line width, enabling static validation. S4
Punching above its weight
Find initial users among GitHub contributors who have recently added Haiku support to their projects. Submit pull requests to public repositories that add only the Haiku check, letting the report itself serve as the demonstration. Then publish diagnostic links for reproducible cases drawn from pending HaikuPorts ports and failed builds. Acquisition content should show how a real failure is narrowed to the first divergent command, rather than broadly promoting cross-platform CI.
Competitors & gaps
- cross-platform-actions/actionGoogle
- It already brings Haiku VMs into GitHub Actions and boots the OS with QEMU. Code and commands can enter the VM via SSH and rsync, and its current documentation lists R1/beta6. S2 For projects that only need builds and command-line tests, this is the lighter path, and maintainers can retain their existing workflows. Its gap is that it provides a general-purpose execution environment rather than defining desktop-app smoke tests. Projects must still script and assess whether windows open, menus work, or files can be read and written through the UI. It also does not proactively align Linux, BSD, and Haiku logs to identify the first command that diverges. After a dependency failure, maintainers must trace source references themselves and write a recipe under HaikuPorts rules. The proposed product must differentiate through these diagnostic and artifact capabilities; simply offering a beta6 VM would be easy to replace.
- Self-managed QEMU images and CI runnersGoogle
- Another common approach is for maintainers to keep their own Haiku QEMU image and connect it to existing CI or self-hosted runners. This gives them complete control over the image, toolchain, and caches, and suits established Haiku maintainers dealing with unusual dependencies. A GitHub App can create, update, and rerun checks through webhooks and the Checks API, so status reporting itself is not scarce. S3 The real gap is that each project must handle image upgrades, concurrent scheduling, failed-run cleanup, and remote access. Desktop applications also require a graphical session, screenshots, and interaction scripts, while stalled jobs require VM reclamation. As multiple repositories maintain their own setups, dependency versions and diagnostic formats can fragment. Small projects are unlikely to maintain this infrastructure long-term for an occasional compatibility fix. Unless the product materially reduces image-maintenance and failure-triage time, it will be hard to persuade teams with existing self-managed workflows to switch.
How it makes money
Charge by Haiku VM execution minute, including basic logs and short-term artifact retention. Offer a small free allowance for public repositories and monthly minute bundles for private ones. Charge extra for remote debugging sessions and longer image-retention periods.
The case against
Graphical smoke tests are prone to false positives. Slow window launches, changed menu names, or lost focus can mark a working application as failed. If maintainers repeatedly receive invalid red checks, they will disable the check altogether. Retaining remotely accessible failed images also adds isolation, credential-revocation, and resource-cleanup burdens. Automatically generated recipes can misidentify transitive dependencies, and low-quality drafts may increase HaikuPorts review work instead. Launch methods vary widely among projects; when presets do not cover them, configuration effort falls back on the user. Before proceeding, prove that a small set of stable actions covers enough desktop projects.