runnerless↗

Implemented in ci-toolkit

Publish BuildBuddy test reports on GitHub PRs

A successful build status tells reviewers that a job finished. It does not put the useful report in front of them. ci-toolkit can take a declared BuildBuddy HTML artifact, verify its relationship to the PR and publish a stable link in a comment that updates as the work changes.

Supported in the private ci-toolkit GitHub App. Runnerless itself is in early development; signing up does not enable this feature.

How it works

01 /

Match a trusted successful build

A .ci-toolkit.yml automation selects a GitHub commit-status context, trusted creator and allowed BuildBuddy invocation host. The publisher independently verifies the invocation’s repository, PR number, successful state and current head SHA before accepting its output.

02 /

Publish one declared report

The buildbuddy.workflow-artifact@v1 source names the HTML file and an expected byte limit. toolkit.public-artifact@v1 writes the verified object with its SHA-256 digest and configured retention. The supported single-report source accepts HTML reports up to 5 MiB.

03 /

Keep the review conversation current

A github.pull-request-comment@v1 action upserts the App-owned comment using a stable marker. The comment can show the report, commit, build invocation, digest and availability deadline. Template expressions are restricted so a repository cannot turn the template into arbitrary mention or external-link injection.

A concrete example

Workflow example

Successful trusted commit status
  → verify BuildBuddy invocation and PR head
  → fetch the declared HTML report
  → verify bytes and SHA-256
  → publish and update the PR comment

Know the boundary

Current limits

Published reports are public. Choose their contents accordingly. This adapter currently targets BuildBuddy; the site does not claim that GitHub Actions, CircleCI or GitLab artifact retrieval is already implemented. Superseded heads lose their links and configured expiry removes stored objects.

Common questions

Will a matching status name alone authorize publication?

No. The publisher also checks the configured creator and invocation origin, then verifies the build’s repository and commit evidence.

Does each rerun create another comment?

The comment action uses an upsert marker, so the report’s existing App-owned comment is updated.

Runnerless / early access

Want this in
your workflow?

Get early access ↗

Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.