Repository navigation
ci: manual, decoupled tagging and npm publishing with append-only changelog - #110
Merged
Merged
Conversation
The release workflow lets conventional-changelog-action regenerate CHANGELOG.md from git history on every release. With its default release-count of 5, releases older than the last five are dropped from the file, and any entry edited by hand is overwritten. Raising release-count only trades this for regenerating an ever-growing history on each release, and still discards manual edits, such as a hand-written changelog for the 0.x initial development phase. Pass the changelog as input-file. The action then generates only the new release and prepends it to the existing content, leaving older entries untouched. Create an empty file when it is missing, since the action reads input-file unconditionally; it is left without a title because anything already in the file ends up below the prepended release.
The release workflow always writes CHANGELOG.md and always infers the version bump from the commits. During initial development (0.x) no changelog is wanted, yet tags and releases should still go through the workflow instead of being made by hand. Inference is also unsafe there: the conventionalcommits preset bumps breaking changes to major even on 0.x, so a single `!` commit in the range would ship 1.0.0. Add a generate_changelog input, off by default, that sets the action's output-file to 'false' when disabled; the action still bumps, commits, tags and runs the lockfile pre-commit hook, it just writes no file. Add a release_type input that forces patch, minor or major through `npm version` plus skip-bump, and reject 'auto' while the version is 0.x. Once 1.0.0 is out, 'auto' works without further changes. Also bump softprops/action-gh-release from v1 to v3, since the v1 runtime is too old for GitHub Actions to run and the "Create GitHub Release" step can't work as is. v3 only moves the runtime to Node 24; the tag_name, body and generate_release_notes inputs used here are unchanged. A separate tag-and-push path built on `npm version` alone was considered and discarded: it would skip the lockfile pre-commit hook and duplicate what the action already does.
The publish workflow runs on every pushed v* tag, so pushing a tag publishes to npm right away, without a deliberate decision to release that version. Tagging and publishing should be independent steps, each triggered by hand. Drop the tag push trigger and keep workflow_dispatch only. Since a manual run can now be started from any ref, fail unless it runs from a tag matching the version in package.json, so a branch or a mismatched tag is never published.
Arthurk12
force-pushed
the
ci/manual-release
branch
from
October 15, 2026 17:46
c43c325 to
78a4883
Compare
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
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.
What does this PR do?
tag_and_release.yml):CHANGELOG.mdasinput-file, so the action generates only the new release and prepends it to the existing file instead of regenerating it from history.generate_changeloginput (off by default). When off, the action still bumps the version, commits, tags and runs the lockfile pre-commit hook, but writes no changelog (output-file: 'false').release_typeinput (auto/patch/minor/major). Explicit types are forced throughnpm version+skip-bump;autokeeps inferring the bump from the commits.autowhile the version is0.x.softprops/action-gh-releasefromv1tov3. Thev1runtime is too old for GitHub Actions to run;v3only moves it to Node 24, and the inputs used here are unchanged.publish.yml):push: tagstrigger; publishing isworkflow_dispatchonly.package.jsonversion.Closes Issue(s)
Closes none
Motivation
conventional-changelog-actionkeeps only the last 5 releases inCHANGELOG.mdby default (release-count). Raising it means regenerating an ever-growing history on every release, and in both cases any entry edited by hand, or a hand-written changelog for the 0.x phase, gets overwritten. Withinput-fileset,release-countis ignored and only the new release is generated (releaseCountis hardcoded to 1 in the action'sgenerateFileChangelog).generate_changelogenabled and the file is created on the first run.conventionalcommitspreset bumps breaking changes to major even on 0.x, so an inferred bump with a single!commit in the range would ship 1.0.0 by accident. While on 0.x the bump type must be chosen explicitly; after 1.0.0,autoworks with no further changes.More
release_type=patch/minor/major(required while on 0.x) andgenerate_changelogas needed.v0.10.0) in "Use workflow from".sync-developat the end. That is the main → develop back-merge PR, not publishing, so it was left unchanged.actionlint1.7.12 passes on both workflows.