runnerless↗

Implemented in ci-toolkit

Conventional Commit checks for GitHub

A well-formed PR title does not guarantee a consistent commit history. Projects that retain individual commits need to inspect each header, especially when version calculation and changelogs depend on commit types. ci-toolkit can enforce this independently of its PR title check.

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 /

Validate individual headers

The ci-toolkit/commit-messages Check Run evaluates the commits on a pull request against the Conventional Commits header shape. Types, optional scopes and the breaking-change marker fit one recognizable structure. The report identifies offending commits rather than leaving the author to inspect the entire history.

02 /

Choose the policy for your merge style

Use the title policy when squash-merge headlines are your primary concern. Add commit_messages when preserving branch history, using merge commits or expecting each commit to carry meaningful release information. Both checks can run together.

03 /

Refuse an incomplete view of history

GitHub’s PR-commits endpoint has a 250-commit ceiling. ci-toolkit compares the API result with the declared commit count and fails closed if the PR exceeds the limit or the response omits commits. It does not pass a policy check after inspecting only part of the history.

A concrete example

Supported .ci-toolkit.yml

api_version: ci-toolkit/v1alpha1
pull_requests:
  commit_messages:
    format: conventional-commits

Know the boundary

Current limits

This is a format check, not proof that a commit description accurately explains the code. It does not rewrite messages for you. Enforcement uses the default-branch policy, and GitHub plan restrictions may prevent the additional synchronous metadata rule.

Common questions

Can a PR disable its own commit policy?

No. The proposed configuration is checked separately; effective policy comes from the trusted default branch.

Does this support arbitrarily large PR histories?

No. The current implementation refuses incomplete evidence beyond GitHub’s 250-commit API limit. Split or simplify the history before relying on this check.

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.