Conversation
PR #22 merged to main and nothing shipped: release.yml only fires on a pushed tag, and the tag was a manual `npm version` step that is easy to forget. Two fixes sat on main unreleased until someone noticed. release-please now recomputes the next version from the conventional commits on main and keeps a release PR open with the bumped package.json, manifest.json, manifest-beta.json and a generated CHANGELOG.md. Merging that PR is the release: it tags, publishes, attaches main.js/manifest.json/styles.css, and appends the versions.json entry. An ordinary merge — docs, chores — cannot mint a version, which is why this is not simply "tag every push to main". versions.json is filled in by version-bump.mjs, the same script the manual flow uses: its key is the version itself, so no generic file updater can write it. Obsidian reads that file from the default branch rather than from the release, so landing it one commit after the tag is harmless. release.yml stays as the manual escape hatch. The tag release-please creates cannot reach it — GitHub does not re-trigger workflows for refs pushed with GITHUB_TOKEN — so the two paths can never publish the same release twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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
PR #22 merged to
mainand nothing shipped.release.ymlonly fires on a pushed tag, and the tag came from a manualnpm versionstep — easy to forget. Two fixes sat onmainunreleased.(
2.4.0-beta.3has since been cut by hand and is published with all three assets, so this PR is only about the automation.)How it works
release-please runs on every push to
main. It reads the conventional commits since the last tag and keeps achore(main): release <version>PR open containing:package.json,package-lock.json,manifest.json,manifest-beta.json,.release-please-manifest.jsonCHANGELOG.mdMerging that PR is the release. It tags, publishes the GitHub release, then the follow-up jobs build and attach
main.js/manifest.json/styles.cssand append theversions.jsonentry.Merging an ordinary PR — docs, chores, refactors — never mints a version. That is the reason for the release-PR hop rather than "tag every push to
main".Versioning
Configured for the current prerelease line, so
fix:on2.4.0-beta.3proposes2.4.0-beta.4. Verified with a dry run against this branch:Release-As: 2.5.0in a commit body pins a version by hand.2.4.0, drop"prerelease": trueand"versioning": "prerelease"fromrelease-please-config.json.versions.jsonrelease-please cannot write it — the key is the version, so no generic file updater fits. The
record-versionjob runsversion-bump.mjs, the same script the manual flow uses, and commits the entry. Obsidian reads that file from the default branch rather than from the release, so landing it one commit after the tag is harmless.Relationship to
release.ymlrelease.ymlstays as the manual escape hatch for a hand-pushed tag. A tag created by release-please cannot reach it — GitHub does not re-trigger workflows for refs pushed withGITHUB_TOKEN— so the two paths can never publish the same release twice. Both now carry a header comment saying so, andMAINTAINING.mddocuments both.After merging
release-please will immediately open a
chore(main): release 2.4.0-beta.4PR covering thisci:commit. Merge it when you want that version out; it is also the end-to-end test of the new pipeline.Checked
npx release-please release-pr --dry-runagainst this branch — correct base version, correct next version, all six files updated.mainhas no protection rule that would block therecord-versionpush.🤖 Generated with Claude Code