runnerless↗

Implemented in ci-toolkit

Automated GitHub releases from Conventional Commits

Release preparation often repeats the same decisions: read the commits, choose a version, write the changelog and create a tag. ci-toolkit derives a proposed release from GitHub state and keeps it in a single pull request, leaving the merge as the visible approval point.

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 /

Derive the next release

The simple strategy reads the configured version file, existing tags and Conventional Commits since the last tagged version. Commit types and configured changelog sections determine the version bump and release notes. Pre-1.0 bump behavior and tag naming are configurable.

02 /

Review one release pull request

The automation maintains one release branch and PR with autorelease: pending. It compares the desired state before writing, so an unchanged evaluation does not create another update. An already-existing next-version tag is reported as a conflict before the PR promises a release it cannot finalize.

03 /

Finalize the reviewed release

After the release PR merges, the Worker uses that merge commit’s configuration to create the tag and optional GitHub Release, update the label and post a summary. A later default-branch configuration edit does not change the policy used to finalize the already-merged release.

A concrete example

Supported .ci-toolkit.yml; simple version-file strategy

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

Availability and limits

Current limits

The current deployment restricts release automation to an operator allowlist and requires accepted GitHub App permissions. It supports the simple version-file strategy; this page does not promise every release-please strategy, ecosystem or monorepo mode. Publishing a release does not itself deploy an application.

Common questions

Can I create a tag without a GitHub Release object?

Yes. skip_github_release: true keeps tag creation while skipping the GitHub Release object.

Does every push create a release?

No. The automation prepares and updates a release PR. Tag and release finalization follow its merge.

Credential handling during publication

Verifying an artifact’s origin does not establish that its contents are free of secrets. Read about accidental CI secret leaks and how modern CI protects secrets for the exposure paths, existing controls, and planned isolation model. Why your publishing service should pull artifacts explains the benefit of fetching and verifying build output in the publisher.

Runnerless / early access

Interested in this 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.