runnerless↗

Implemented in ci-toolkit

Validate CI automation configuration in a PR

An automation configuration mistake can disable several workflows at once. ci-toolkit adds a focused check when a PR changes .ci-toolkit.yml, including adding or removing the file. Authors see parser and sanity errors before the proposed configuration becomes authoritative.

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 /

Check only when the file changes

The ci-toolkit/config Check Run compares the file at the PR head and base. Byte-identical files do not produce an extra check. A proposed removal succeeds with a notice that no configuration will apply after merge.

02 /

Validate the complete document

One shared parser checks pull request policies, artifact automations and releases. It rejects duplicate keys, YAML aliases, unsupported shapes and documents above 64 KiB. At least one subsystem must be declared. When releases are configured, the version file must exist at the PR head and contain a valid semantic version.

03 /

Preview without executing untrusted changes

This check reads proposed files and reports what they declare. It does not fetch BuildBuddy artifacts, publish files, rewrite rulesets or create releases from PR-head configuration. Effective automation policy comes from the trusted branch after merge.

A concrete example

Supported config; version.txt must also exist

api_version: ci-toolkit/v1alpha1
releases:
  uses: toolkit.release-please@v1
  with:
    strategy: simple
    version_file: version.txt
    changelog_path: CHANGELOG.md

Know the boundary

Current limits

The configuration check is informational and is not automatically added to the managed ruleset as a required check. A successful parse also does not verify that every external integration is operational. One invalid section fails the whole document, so review configuration changes carefully.

Common questions

Does a green config check execute the proposed automation?

No. It is read-only and does not act on PR-head automation settings.

Why does a missing version file fail the check?

Release configuration needs a valid version source at the proposed head. Checking that file catches a release failure before the configuration is merged.

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.