runnerless↗

Runnerless concept · not available yet

Artifact publishing across CI providers

Reviewers should be able to find a report without learning a different download path for every CI provider. Runnerless could extend the existing BuildBuddy publishing model into provider adapters that produce a consistent artifact record: repository, commit, filename, size, digest and expiry.

Design direction for Runnerless. The workflow below is not implemented or available to install.

The proposed workflow

01 /

Normalize the handoff, preserve the evidence

Each provider adapter would need to verify the build’s repository, commit and outcome using that provider’s trusted API. A common record is useful only if it preserves that evidence. Matching a filename or accepting an arbitrary URL from a webhook would not establish provenance.

02 /

Publish a predictable review surface

After verification, a shared publication step could expose a report link or folder table and update an existing PR comment. Reviewers would see the same commit reference and availability deadline whether the build ran in GitHub Actions, CircleCI, GitLab CI or BuildBuddy.

03 /

Make storage and expiry deliberate

HTML reports, binary bundles and manifests need different serving rules. Retention should remove abandoned outputs and keep public exposure explicit. The current toolkit already distinguishes untrusted HTML from forced data downloads and supplies checksums; future adapters should preserve those boundaries.

A concrete example

Workflow example

Planned provider adapter
  GitHub Actions / CircleCI / GitLab CI / BuildBuddy
    → verify repository + commit + build outcome
    → normalized artifact record
    → publish with digest and expiry
    → update the review link

Know the boundary

What is still to build

BuildBuddy artifact retrieval and publication exist in ci-toolkit today. The GitHub Actions, CircleCI and GitLab CI adapters described here are ideas for Runnerless and are not implemented. No cross-provider credentials are requested by this site.

Common questions

Does Runnerless already download GitHub Actions artifacts?

No. This page describes a planned adapter. The currently implemented publisher reads BuildBuddy artifacts.

Would every artifact have to be public?

The existing toolkit publication is public. Additional visibility choices would need a separate access and storage design; they are not promised by this concept.

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.