Adopt release-please + tag-gated production deploys#124
Merged
Conversation
Deploying launchpad with
|
| Latest commit: |
120ed87
|
| Status: | ⚡️ Build in progress... |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
launchpad | 120ed87 | Commit Preview URL Branch Preview URL |
May 15 2026, 09:57 PM |
TheMeinerLP
changed the title
semantic-release was wired up via release.config.cjs and the `pnpm release` script but no workflow ever invoked it. After a year there are still zero git tags, no CHANGELOG.md and package.json is stuck on `0.0.0-development`. Dropping the dead config and devDeps now so the follow-up commit can wire up release-please as the single source of truth for versioning.
Release Please replaces the dead semantic-release config with a PR-based workflow that fits this project better: - Pushes to main append to a long-lived "Release Please" PR that lists every conventional commit since the last tag, grouped into feat / fix / perf / refactor / docs / ci sections. - Merging that PR creates the git tag, bumps package.json (consumed by nuxt.config's appConfig.version), updates CHANGELOG.md and publishes a GitHub Release. - Until the PR is merged, ordinary commits keep flowing into main and trigger Cloudflare Pages previews as before; releases happen on a cadence the team controls instead of one per `feat` commit. Starts from version 0.0.0 in the manifest so the next breaking change or feat lands at 0.1.0 (bump-minor-pre-major is enabled). Chore, build, test and style commits stay out of the changelog by default but still count toward the next bump.
Cloudflare Workers Builds' Git integration watches branches, not tags, so tag-gated production deploys need a branch that only moves on releases. This workflow runs on every `v*` tag (the tags release-please cuts when its release PR is merged) and fast-forwards a `release` branch to the tagged commit. Pointing the Workers production branch at `release` via the dashboard's branch control (see PR description) then means: - pushes to main → Workers preview deploys only - a merged release PR → tag → release branch moves → Workers production build No force push: release-please tags are always on main's linear history, so `release` only ever fast-forwards. Uses the default GITHUB_TOKEN (contents: write); `release` must stay unprotected so the token can push to it. Cloudflare reacts to its own Git integration, so GITHUB_TOKEN's workflow-loop-prevention does not suppress the deploy.
TheMeinerLP
force-pushed
the
claude/release-please
branch
from
b2562b4 to
120ed87
Compare
6 tasks
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.
Summary
Two related changes (rebased onto current
main, which already runs thecloudflare_moduleWorkers preset via #125/#126/#128):semantic-releasewith release-please — a PR-based versioning workflow.mainbecomes preview-only, releases drive production.Why
semantic-releasewas configured a year ago (release.config.cjs,pnpm release, six@semantic-release/*devDeps) but never ran: no workflow invoked it, no git tags, noCHANGELOG.md,package.jsonstuck at0.0.0-development. And Cloudflare currently deploys production on every push tomain, with no link to releases.Commits
chore(release): remove unused semantic-release configurationchore(release): adopt googleapis/release-please for versioningci(release): promote release-please tags to a deploy branchreleasebranch on everyv*tag.How the pipeline works after merge
package.jsonbump). It never touchesnuxi build, thecloudflare_modulepreset, or thewrangler/D1 config.nuxt.config.appConfig.versionreadspackage.json, so production finally shows a real version instead of0.0.0-development.releaseonly ever fast-forwards.GITHUB_TOKEN. Cloudflare reacts to its own Git integration, so GitHub's workflow-loop-prevention on the token does not suppress the production build.In the Cloudflare dashboard, Workers & Pages → (your Worker) → Settings → Build → Branch control:
release(currentlymain).mainand PRs still produce preview/version deploys.release— the promote workflow pushes to it withGITHUB_TOKEN.Until step 1 is done,
releaseis still created/updated by the workflow but Workers keeps buildingmainfor production — harmless, just not yet tag-gated.Configuration highlights
release-type: node,bump-minor-pre-major: true→ pre-1.0,feat:→ minor,fix:→ patch.refactor,ci,docs;chore/build/test/stylehidden but still trigger a release.include-v-in-tag: true→ tags asv0.1.0.0.0.0; the first release PR decides the starting version from accumulated commits.Test plan
mainand opens a Release PRreleasev0.1.0tag →promote-release.ymlruns →releasefast-forwardsrelease;mainpush only produces previews0.1.0(was0.0.0-development)CHANGELOG.mdcreated,package.jsonbumped onmain