✨ Add flopha.toml and flopha release command#30
Open
sjquant wants to merge 2 commits into
Open
Conversation
One-command, config-driven releases: computes the version bump, syncs it into manifest files (Cargo.toml, package.json, pyproject.toml, or arbitrary regex targets), commits, creates an annotated tag, pushes, generates a changelog, and creates a GitHub Release — all driven by a checked-in flopha.toml instead of ad-hoc shell orchestration. Supports `flopha release --dry-run` to print the release plan without side effects.
- flopha release with [changelog] enabled=true always failed: it asked for commits up to the not-yet-created tag. Build the changelog against HEAD instead, substituting the tag into the title placeholder directly. - Regex manifest sync now updates every match (not just the first) and treats the replacement as a literal string instead of expanding `$1`/ `$name` capture references. - Manifest sync now computes every target before writing any of them, so a later target failing to parse no longer leaves earlier ones rewritten on disk with nothing committed. - Reject a detached HEAD up front when manifest targets are configured, instead of failing obscurely after the commit/tag are already made locally with nowhere to push. - Reuse TagVersionSource::create and service::pre_release_tag instead of re-deriving tag creation and pre-release formatting inline. - Error instead of silently defaulting to 0 when version.pattern doesn't capture every version component. - Clarify the error when GitHub Release creation fails after the tag was already pushed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every team currently re-derives its own release glue (this repo's
release.yml+action/run.shincluded): bump a version, editCargo.toml/package.jsonby hand, tag, push, write a changelog, and create a GitHub Release. flopha already has the pieces for each step individually (next-version,changelog); this adds a single orchestrating command driven by a checked-inflopha.toml, so the release contract lives in a config file instead of bash quoting, and manifest sync — the one piece lightweight competitors (svu, git-cliff) skip — is handled natively.Changes
flopha releasecommand (aliasrel) that runs the full pipeline: compute bump → sync manifests → commit → annotated tag → push → changelog → GitHub Release.flopha.tomlschema (src/config.rs) covering[version],[changelog],[release], and repeatable[[manifest]]targets.src/manifest.rs: syncs the computed version intoCargo.toml/pyproject.toml(viatoml_edit, preserving formatting and comments),package.json(viaserde_json), or an arbitrary file via a user-supplied regex + replacement.src/github.rs: creates the GitHub Release by shelling out togh(same mechanismaction/run.shalready uses), resolving theowner/reposlug from theoriginremote unless overridden in config.flopha release --dry-runprints the release plan (bump, from/to tag, manifest files that would be touched, changelog preview) without making any changes.src/service.rs(resolve_increment,next_pre_release_number,build_changelog) sonext-version/changelogand the newreleasepipeline share one implementation instead of duplicating it.README.mddocumentation for the new command andflopha.tomlschema.version.source = "branch"is intentionally unsupported byrelease— manifest sync, commits, and GitHub Releases all assume tag-based versioning.Generated by Claude Code