Repository navigation
ci: add package-scoped release automation - #13
Merged
Merged
Conversation
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.
Parsh's independently versioned packages need release automation that targets their published
pkg/manifests and derives both the version and release history from commits for the package being shipped.Adds a private
@repo/internal-scriptsworkspace for release preparation, validation, PR body generation, and release notes. A shared git-cliff configuration selects Conventional Commits touchingpackages/<package>/**, ignores release housekeeping, and recognizes only the selected package's stable version tags. Git-cliff automatically infers patch bumps from fixes and other releasable changes, minor bumps from features, and minor bumps from breaking changes before 1.0.0, and major bumps from breaking changes at 1.0.0 or later.The manual
prepare-releaseaction accepts only the package name and opens a PR updating its manifest,CHANGELOG.md, and Bun lockfile. Before the first package tag, git-cliff uses the existing manifest version as the bump baseline and includes the package's full history. Later releases require the manifest and last package tag to agree. Preparing a release fails when there are no new releasable package commits; changelogs are regenerated from history.Pushing
<package>-v<version>validates the version, tag target, and ancestry onmain, runs checks/tests and a fresh build, generates package-specific release notes, publishes the selected package through npm OIDC with provenance, and creates a GitHub release using those notes. The shared prepare action reads Bun and Node versions from the root package.json (packageManagerandengines.node), including the Node 24 pin and npm registry setup. Publishing reuses that setup. Contributor documentation covers tag conventions, npm trusted-publisher setup, and optionalRELEASE_TOKENfor CI on bot-created PRs. AGENTS.md records the internal release package and commit-based semver convention.Validation with Bun 1.4.3 and Node 24:
bun fix:codestyle,bun check:all,bun run test,bun run build, andactionlintpassed. Nineteen release integration tests cover automatic patch/minor/major inference on 0.x and 1.x versions, pre-1.0 breaking-change minor bumps, breaking-change footers, sibling commit/tag exclusion, current-tag release notes, initial releases, lockfile updates, empty releases, and invalid package/version/tag/ancestry inputs. Actual release CLI runs against the repository history confirmed that core, codegen, env, and files each advance to 0.1.0, with diffs restricted to their own manifest/changelog and bun.lock, and release notes matching the changelog. Existing package artifact dry runs and the fresh publish build were also verified.Actual npm publishing has not been run; npm trusted publishers must be configured before the first automated release.