ci: build dist at release time and keep release tags on main - #19
Merged
Conversation
The release workflow built dist/ at release time and force-moved the release tag (e.g. v0.2.0) onto a separate "chore: add dist" commit that is not part of main's history. release-please anchors its changelog on the previous release tag's commit, so once the tag pointed off main it could no longer detect the release boundary and re-collected already-released commits on every run (e.g. the 0.3.0 PR re-listed every 0.2.0 feature and bumped minor instead of patch). Commit the Action bundle (dist/index.js and its runtime companions) to main instead, matching the model already documented in DEVELOPMENT.md and enforced by the CI dist freshness check. The release tag now stays on the main release commit, and the workflow only moves the floating major-version tag. dist/cli/ and type declarations remain untracked (built on demand and at npm publish).
Collapse dist/index.js (and its map/sourcemap-register companions) in GitHub diffs and exclude them from language statistics, since they are generated build artifacts committed only so the Action runs via uses:@vx.
Rebuild the committed Action bundle in CI and push it back to the PR branch so contributors never have to run 'npm run build' locally. Fork PRs (read-only token) fall back to a verify-only job that fails if the bundle is stale. Drop the now-redundant dist freshness check from the main CI workflow.
7nohe
changed the title
Switch to building the Action bundle during the release run rather than committing it to the repository on every change: - dist/ is gitignored again; contributors never build it or carry it in a PR diff. - On release, the workflow builds the bundle, commits it on top of main, and points the release tag (and the major tag) at that commit. The tag stays on main's history, so release-please keeps detecting the previous release boundary correctly. This reverts the dev-time dist commit and the per-PR auto-commit workflow in favor of the release-time approach. The .gitattributes entries marking the bundle as generated are kept, so the bundle the release workflow commits stays collapsed in diffs and out of language stats.
7nohe
force-pushed
the
fix/release-workflow-commit-dist
branch
from
June 24, 2026 08:53
3dfb38c to
939ab5e
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
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.
Problem
release-please keeps re-listing already-released commits and over-bumping the version (e.g. the open
chore(main): release 0.3.0PR re-lists every 0.2.0 feature when only onefix:has landed since v0.2.0). The 0.2.0 changelog already shows the same duplication of 0.1.6's entries.Root cause
The old
build-and-tagjob builtdist/at release time, committed it as a separatechore: add dist for vXcommit created from a detached checkout of the tag, and force-moved the release tag onto that commit. The result: every release tag (v0.1.6,v0.2.0,v0) points to a commit that is not in main's history. release-please anchors its changelog/version on the previous release tag's commit while walking main; since no recent release tag is reachable on main, it re-collects commits all the way back, inflating both the changelog and the bump.Fix
Keep building the bundle at release time (so it stays out of normal dev PRs), but commit it on top of main and point the tags at that on-main commit:
dist/stays gitignored — contributors never build it or include it in a PR diff.release_created == true), the workflow builds the Action bundle, commits it on top ofmain, pushesmain, then points the release tag and the floating major tag at that commit.git pull --rebaseguards against a concurrent push tomainduring the release run.The previous attempt in this PR (committing dist in dev + a per-PR auto-commit workflow) was reverted in favor of this release-time approach.
Trade-offs
github-actionsbot to be able to push tomain(the workflow hascontents: write). Ifmainenforces a protected-branch rule that blocks bot pushes, that rule must allow it.mainbetween releases has no committed bundle; only release tags carry one.uses: ...@vX(tags) always resolves a ready-to-run build;uses: ...@maindoes not.Follow-up (not in this PR — needs owner decision)
The existing
v0.2.0tag is still off main, so the next release-please PR may mis-walk once. Re-pointingv0.2.0to its real release commit would force-push a published tag (and drop dist from@v0.2.0), so it is intentionally left out. From the first release tagged under this workflow onward, boundaries are correct automatically — the simplest path is to manually correct that one transitional release PR to the expected version (0.2.1) before merging.