feat: extract version bumping into reusable bump-npm-version workflow#59
Merged
kevwilliams merged 5 commits intomainfrom Apr 2, 2026
Merged
feat: extract version bumping into reusable bump-npm-version workflow#59kevwilliams merged 5 commits intomainfrom
kevwilliams merged 5 commits intomainfrom
Conversation
Merged
5 tasks
scotwells
reviewed
Mar 26, 2026
Comment on lines
+238
to
+246
| - name: Create GitHub Release | ||
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: | | ||
| gh release create ${{ steps.version.outputs.new-version }} \ | ||
| --title "${{ inputs.package-name }} ${{ steps.version.outputs.new-version }}" \ | ||
| --generate-notes \ | ||
| --repo ${{ github.repository }} | ||
|
|
Contributor
There was a problem hiding this comment.
Feels odd to have this baked into the NPM publishing workflow. This feels like it should be a separate workflow since npm publishing is just part of the release creation process.
Contributor
Author
There was a problem hiding this comment.
Yea I agree actually this needs to be moved to the caller. Ill adjust it.
npm publishing is one step in a release, not the whole thing. Callers are responsible for creating the GitHub Release after publish.
The caller is now responsible for bumping the version, tagging, and pushing before invoking this workflow. publish-release just reads the version from package.json, builds, and publishes — no git operations. This keeps the npm publish workflow focused on a single concern and allows callers to coordinate the version number across multiple steps (npm publish, GitHub Release, container builds, etc.).
scotwells
approved these changes
Apr 2, 2026
kevwilliams
added a commit
to datum-cloud/activity
that referenced
this pull request
Apr 2, 2026
…atch (#160) ## Summary - Removes the `release: published` trigger (was the source of the circular tag problem) - Adds `workflow_dispatch` trigger with `bump-type` input (patch/minor/major) as an escape hatch for "I forgot to add the label" - Adds a `detect-mode` job that reads the merged PR's labels to decide dev vs release mode - Passes `bump-type` through to the reusable workflow so `workflow_dispatch` works without a PR to read labels from ## How releases work now **Normal flow (merge with label):** 1. Add `release`, `release:minor`, or `release:major` label to the PR before merging 2. Merge to `main` — CI detects the label, runs in release mode, bumps version, tags, publishes to npm, creates GitHub Release **Forgot the label (escape hatch):** 1. Go to Actions → "Publish UI to NPM" → Run workflow 2. Choose bump type (patch/minor/major) 3. Workflow runs in release mode manually **No label (default):** - Publishes a dev build (`x.y.z-dev.{sha}`) to the `@dev` npm dist-tag only ## Dependency Requires `datum-cloud/actions` datum-cloud/actions#59 to be merged and tagged as `v1.13.0` first — this workflow references that version. ## Test plan - [ ] datum-cloud/actions#59 merged and tagged `v1.13.0` - [ ] Update the `@v1.13.0` reference in this file once that tag exists - [ ] Merge a PR without a release label → confirm dev build published, no GH Release created - [ ] Merge a PR with `release:minor` label → confirm minor version bump + GH Release - [ ] Trigger `workflow_dispatch` with `major` → confirm major bump + GH Release
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.
Summary
Motivation
The previous `publish-release` job did too much: it detected bump type from PR labels, bumped the version, pushed the tag, built, and published — all in one job. This made it hard to reuse across repos and coupled version calculation to the publish step.
The new design separates concerns:
Callers compose them as sequential jobs, passing `new-version` between them. The resolved version is available as an output before any git operations run.
Dependency
`datum-cloud/activity` PR #160 references `v1.13.0` of both `bump-npm-version.yaml` and `publish-npm-package.yaml` — this PR should be merged and tagged `v1.13.0` first.
Test plan