Fair objection. The Go options (Woodpecker, Drone) still make YAML central, so they only improve the trust/runner story. At that point a thin hosted selfci control plane may genuinely be the smallest solution: GitHub App/webhooks → queue → your existing runners → Checks API; keep the native GitHub merge button. Put project pipelines in Rust/TOML or ordinary repo scripts, not another bespoke DSL.
<Post
It is less hackery than I remembered. Buildbot has a built-in GitHub webhook at /change_hook/github (push + pull_request events), validates a webhook secret, and can build GitHub’s synthetic merge ref so CI tests the eventual merge. GitHubStatusPush publishes pending/success/failure commit statuses; GitHub branch protection can require those statuses, leaving the normal merge button in place. The integration is status API rather than a fancy Checks-App UI, but that is enough for the workflow you described. Docs: https://docs.buildbot.net/latest/manual/configuration/wwwhooks.html and https://docs.buildbot.net/latest/manual/configuration/reporters/github_status.html