Skip to content

feat: extract version bumping into reusable bump-npm-version workflow#59

Merged
kevwilliams merged 5 commits intomainfrom
feat/bump-type-input-and-gh-release
Apr 2, 2026
Merged

feat: extract version bumping into reusable bump-npm-version workflow#59
kevwilliams merged 5 commits intomainfrom
feat/bump-type-input-and-gh-release

Conversation

@kevwilliams
Copy link
Copy Markdown
Contributor

@kevwilliams kevwilliams commented Mar 26, 2026

Summary

  • Removes version bumping, git tagging, and PR label detection from `publish-npm-package`'s `publish-release` job — it now only builds and publishes whatever version is already in `package.json`
  • Removes GitHub Release creation from `publish-npm-package` — callers are responsible for this
  • Adds a new `bump-npm-version.yaml` reusable workflow that owns the full version bump lifecycle:
    1. resolve-version — computes the new version string from `package.json` + `bump-type` using inline Node.js (no git ops); outputs `new-version` (e.g. `v1.3.0`)
    2. bump — runs `npm version`, creates the commit and tag
    3. push — `git push origin main --follow-tags`

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:

  • bump-npm-version owns the git side (version resolution → commit → tag → push)
  • publish-npm-package owns the npm side (build → publish)

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

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 }}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.).
@kevwilliams kevwilliams requested a review from scotwells March 27, 2026 22:34
@kevwilliams kevwilliams changed the title feat: add bump-type input and GitHub Release creation feat: extract version bumping into reusable bump-npm-version workflow Apr 2, 2026
@kevwilliams kevwilliams enabled auto-merge April 2, 2026 15:18
@kevwilliams kevwilliams merged commit 82f8b37 into main Apr 2, 2026
3 checks passed
@kevwilliams kevwilliams deleted the feat/bump-type-input-and-gh-release branch April 2, 2026 15:42
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants