dev-kitx/Smart GitHub Release

Auto semantic versioning, smart changelog, SHA-256 checksums, pre-release channels, and job summaries.

View on GitHub

Trust Signals

Scorecard Score: not yet scored
Maintenance Recency: Activelast commit Jul 10, 2026
License: MIT

Pinned Snippet

workflow.ymlSHA-pinned

uses: dev-kitx/smart-gh-release@40831c650cf37cd0ed80aef555b2f2e19dfa8bb7 # v0.6.7

tags can be moved; commit SHAs can't. why a SHA?

Inputs

name	description	required	default
token	GitHub token with repo permissions	no	${{ github.token }}
tag	Explicit release tag (e.g. v1.2.3). If omitted, set auto_version: true to have the tag computed from conventional commits.	no	—
version_prefix	Prefix prepended to auto-generated version numbers	no	v
auto_version	Analyse conventional commits since the last tag and automatically determine the next semantic version (major / minor / patch).	no	false
initial_version	Seed version used when no prior semver tags exist (only relevant with auto_version: true).	no	0.1.0
name	Release title. Defaults to the tag name when omitted.	no	—
body	Custom text prepended to the auto-generated changelog.	no	—
draft	Publish the release as a draft.	no	false
prerelease	Mark the release as a pre-release.	no	false
prerelease_channel	Pre-release channel identifier: alpha \| beta \| rc. When used with auto_version, produces versions like 1.2.0-beta.3.	no	—
target_commitish	Commit SHA or branch name to tag. Defaults to the SHA that triggered the workflow.	no	—
changelog_sections	JSON array to customise changelog sections. Each object must have: { "types": ["feat"], "label": "Features", "emoji": "✨" }	no	—
exclude_types	Comma-separated conventional commit types to omit from the changelog.	no	ci,style,test
include_contributors	Append a Contributors section that credits everyone who committed.	no	true
files	Newline-separated file paths or glob patterns to upload as release assets. Example: dist/.zip dist/.tar.gz	no	—
generate_checksums	Auto-generate a SHA-256 checksums file and upload it alongside other assets. The file lists every asset's hash in the standard "<hash> <filename>" format.	no	true
checksum_file	Name of the generated checksum file.	no	checksums.txt
fail_on_unmatched_files	Fail the action if any glob pattern in `files` matches no files.	no	false
required_assets	Newline-separated glob patterns that MUST match at least one resolved file. The release is aborted when any pattern goes unmatched — useful for ensuring all platform binaries are present before publishing.	no	—
bump_version_in_files	Newline- or comma-separated list of repo-relative file paths whose version string should be bumped to match the new release version. The version is committed onto the same branch as CHANGELOG.md so it lands in the default branch together when the PR is merged. Supported files and the pattern that is updated: package.json "version": "x.y.z" pyproject.toml version = "x.y.z" setup.cfg version = x.y.z setup.py version="x.y.z" __init__.py / _version.py / version.py __version__ = "x.y.z" Cargo.toml version = "x.y.z" *.gemspec .version = "x.y.z"	no	""
update_existing	When a release for the given tag already exists, update it instead of failing. Existing assets are preserved; new assets are appended.	no	false
auto_release	Controls when the GitHub Release is created. true (default): Create the release immediately on every push, then open a pull request from the `smart-changelog` branch to update CHANGELOG.md. Merge that PR at your convenience — it does not gate the release. false: Open (or update) a pull request from the `smart-release` branch with an updated CHANGELOG.md. The GitHub Release is created only when that PR is merged, giving you a human review gate before publishing. Commits accumulate across multiple pushes into the same open PR. Requires `pull-requests: write` permission in your workflow.	no	true
comment_on_prs	After publishing a release, post a comment on every merged PR that was included in the release pointing back to the release URL. Set to false to disable.	no	true
generate_badge	Generate a shields.io endpoint badge file at `.github/badges/release.json` and commit it onto the same PR branch as CHANGELOG.md. Once merged, the file can be served via raw.githubusercontent.com as a live dynamic badge that always reflects the latest release. Add the following to your README to display it: [![Release](https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2F{owner}%2F{repo}%2Fmain%2F.github%2Fbadges%2Frelease.json)](https://github.com/{owner}/{repo}/releases/latest) Use the `badge_markdown` output for a ready-to-paste version.	no	false
dry_run	Compute the next version and generate the changelog but do not create the GitHub Release, open any PRs, upload assets, or publish the major tag. All outputs are still set so you can inspect what would happen. Useful for validating your workflow configuration before enabling it in production.	no	false
skip_if_no_commits	Skip creating a release when there are no commits since the last tag. Prevents empty or meaningless releases when a workflow is triggered by a non-code change (e.g. a README update that slipped through paths-ignore).	no	false
publish_major_tag	After publishing the release, create or force-update a floating major version tag (e.g. v1) that always points to the latest release commit. Follows the same clamping rule as the tag-major workflow: v0.x.x releases update v1, v1.x.x updates v1, v2.x.x updates v2, etc. Set to false (default) when you want to gate the major tag behind an approval step — use major_tag_only: true in a separate job with an environment protection rule instead.	no	false
major_tag_only	Skip the full release flow and only publish the floating major tag. Requires the `tag` input to be set explicitly (e.g. from a prior job's tag_name output). Designed for use in a second workflow job protected by a GitHub Environment with required reviewers so the major tag update can be approved before it affects all consumers pinned to the floating tag. See the Floating Major Tag section in the README for the full pattern.	no	false
create_discussion	Create a GitHub Discussion announcing this release. Requires the `discussions: write` permission and an existing category.	no	false
discussion_category	Name of the repository Discussion category to post into.	no	Announcements

Outputs

name	description
release_id	Numeric ID of the created / updated release.
release_url	HTML URL of the release page.
upload_url	Asset upload URL (useful for subsequent upload steps).
tag_name	The resolved tag name (e.g. v1.3.0).
version	Version string without prefix (e.g. 1.3.0).
assets_uploaded	Number of assets successfully uploaded.
changelog	The full generated changelog in Markdown.
bump_level	Detected version bump: major \| minor \| patch.
badge_url	shields.io endpoint URL for the release badge (set regardless of whether generate_badge is enabled).
badge_markdown	Ready-to-paste Markdown for embedding the release badge in a README (set regardless of whether generate_badge is enabled).
skipped	Set to "true" when the release was skipped (e.g. skip_if_no_commits: true and no commits were found). "false" otherwise.
major_tag	The floating major tag that was created or updated (e.g. v1). Set when publish_major_tag: true. Empty string otherwise.
pr_url	HTML URL of the opened or updated pull request. Set when auto_release: true (smart-changelog PR) or auto_release: false on a non-merge push (smart-release PR).