ac526fb54d
Each shippable artifact (prb, probod server group, probod-bootstrap, @probo/n8n-nodes-probo, @probo/cookie-banner) now has its own version file, its own CHANGELOG.md, its own annotated-tag scheme of the form <track>/v<version>, and its own GitHub Actions release workflow. The unified release.yaml is removed; the unified CHANGELOG.md becomes a short index pointing at each per-track file, with the prior history preserved in CHANGELOG.archive.md. Probod's CHANGELOG carries the post-split monorepo releases (0.174.0 through 0.181.0) so the server-group history stays continuous and the probod docker image keeps its existing version line. contrib/claude/release.md is split into contrib/claude/release/ with one entrypoint per track plus a README that drives the agent: detect which tracks have user-facing commits since their last tag and skip tracks with no relevant changes, so a release request never tags an unchanged track. The cookie-banner and n8n-node entrypoints add an explicit npm run build step after the version bump (build.mjs bakes package.json's version into __SDK_VERSION__) so compile errors and package-lock.json updates are caught before tagging. Signed-off-by: Bryan Frimin <bryan@getprobo.com>
2.8 KiB
Release @probo/cookie-banner
Entrypoint for releasing the cookie banner SDK. Read README.md first for overall flow, changelog rules, and the non-empty-track guarantee.
Track facts
- Tag pattern:
@probo/cookie-banner/v* - Version source:
packages/cookie-banner/package.json - Changelog:
packages/cookie-banner/CHANGELOG.md - Workflow:
.github/workflows/release-npm-cookie-banner.yaml - Path filter (for log/scoping):
packages/cookie-banner
Important: build script bakes the version
packages/cookie-banner/build.mjs reads version from package.json
and exposes it to the bundle as the __SDK_VERSION__ define. The SDK
uses this value at runtime (e.g. when calling the Probo REST API), so
the build must run after the version bump to make sure the new
version is what gets published. The release CI workflow does run the
build, but we still run it locally as part of the release commit so:
- compile errors are caught before tagging,
- any tracked side-effects (
package-lock.json, etc.) are part of the sameRelease @probo/cookie-banner/v<version>commit.
Steps
-
From a clean
main, list commits since the last@probo/cookie-bannertag:git log $(git describe --tags --abbrev=0 --match='@probo/cookie-banner/v*')..HEAD --oneline \ -- packages/cookie-bannerIf the list is empty (or contains only non-user-facing commits), do not release this track.
-
Decide the version bump (PATCH for fixes, MINOR for features).
-
Bump the version using npm so
package.jsonandpackage-lock.jsonstay consistent:npm --workspace @probo/cookie-banner version <X.Y.Z> --no-git-tag-version -
Run the workspace build so
__SDK_VERSION__is rebuilt from the newpackage.jsonand any compile error surfaces before we tag:npm --workspace @probo/cookie-banner run builddist/is gitignored, so this step does not produce checked-in build artifacts — but it must succeed for the release to be valid. -
Write the new entry in
packages/cookie-banner/CHANGELOG.mdfollowing the rules in README.md. -
Show the user the changelog diff and the new version. Wait for confirmation.
-
Stage the files modified by the version bump and changelog edit (typically
packages/cookie-banner/package.json,packages/cookie-banner/CHANGELOG.md, andpackage-lock.json). Commit subject:Release @probo/cookie-banner/v<version>. No body. -
Annotated tag:
git tag -a @probo/cookie-banner/v<version> -m "@probo/cookie-banner/v<version>". -
Push:
git push origin main --follow-tags.
CI workflow release-npm-cookie-banner.yaml verifies the tag matches
package.json, runs the build again, publishes to npm with provenance +
SBOM, and creates a GitHub Release.