ci: add publish-on-tag workflow

[amittell]

Summary

• Adds publish.yml workflow triggered on v* tags
• Runs full lint + test before publishing
• Verifies tag version matches package.json (prevents mismatches)
• Publishes to npm with provenance and public access
• Creates GitHub release with auto-generated notes
• Requires NPM_TOKEN secret to be set in repo settings

Also done (outside this PR)

• Branch protection enabled on main: PRs required, lint-test CI must pass, no force pushes

Setup needed

Add NPM_TOKEN as a repository secret: Settings > Secrets and variables > Actions > New repository secret

Test plan

• Verify CI passes on this PR
• After merge, test with next real release (bump version, tag, push tag)

Summary by CodeRabbit

• Chores
  • Implemented automated npm publishing workflow triggered on version tags.
  • Runs linting and tests before publishing to ensure release quality.
  • Validates that the pushed tag version matches the package version before publishing.
  • Publishes package with provenance and creates a GitHub release with generated release notes.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1ec85c39-f20b-4cea-b854-8e5fb69b7011

📥 Commits

Reviewing files that changed from the base of the PR and between 4c3b297 and 237c429.

📒 Files selected for processing (1)

• .github/workflows/publish.yml

---

📝 Walkthrough

Walkthrough

A new GitHub Actions workflow /.github/workflows/publish.yml runs on pushed tags matching v*. It runs lint/tests, validates the tag version against package.json, publishes the package to npm with provenance, and creates a GitHub release.

Changes

Cohort / File(s)	Summary
Publish Workflow /.github/workflows/publish.yml	Adds a CI workflow triggered on pushed tags v*. Defines a test job (checkout, Node 22, npm ci, npm run lint, npm test) and a dependent publish job (registry setup, version match check between tag and package.json, npm publish --provenance --access public, and gh release creation).

Sequence Diagram(s)

sequenceDiagram
    participant Dev as Developer (push tag)
    participant GH as GitHub Actions
    participant Repo as Repository
    participant Node as Node.js runner
    participant NPM as npm Registry
    participant GHCLI as GitHub (gh) API

    Dev->>GH: push tag (vX.Y.Z)
    GH->>Repo: checkout code
    GH->>Node: setup Node 22, npm cache
    Node->>Repo: run npm ci, npm run lint, npm test
    alt tests pass
        GH->>Repo: checkout again (publish job)
        GH->>Node: setup Node 22 with registry auth
        Node->>Repo: read package.json version
        Node->>GH: compare tag (strip leading v) with package.json
        alt versions match
            Node->>NPM: npm publish --provenance --access public (NODE_AUTH_TOKEN)
            Node->>GHCLI: gh release create --generate-notes
        else versions differ
            Node-->>GH: fail job (version mismatch)
        end
    else tests fail
        Node-->>GH: fail publish
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 I hopped a tag across the trees,
Lint and tests upon the breeze,
Version checked, the carrots gleam,
npm nibble, release dream,
A tiny hop — a public stream! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'ci: add publish-on-tag workflow' clearly and concisely summarizes the main change: adding a new CI workflow for publishing on tags.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/publish-workflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Adds a tag-triggered GitHub Actions workflow to publish the package to npm and create a GitHub Release, ensuring CI passes and the git tag matches package.json before publishing.

Changes:

• Introduces .github/workflows/publish.yml triggered on v* tags.
• Runs npm ci, lint, and tests prior to publishing.
• Verifies tag version matches package.json, then publishes to npm (with provenance) and creates a GitHub release with generated notes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/publish.yml (1)

47-51: Consider: gh release create will fail if a release already exists for the tag.

This is likely acceptable behavior for your use case (preventing duplicate releases), but if you want idempotency for re-runs, you could add || true or check for existing releases first. Not critical—just noting for awareness.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish.yml around lines 47 - 51, The "Create GitHub
release" step runs gh release create "$TAG_REF" --generate-notes which will fail
if a release for TAG_REF already exists; make the step idempotent by either
appending a no-op on failure (e.g., add "|| true") or by first checking for an
existing release with gh release view "$TAG_REF" and only calling gh release
create when that check fails so the workflow won't error on re-runs; update the
step that sets GH_TOKEN and TAG_REF and the command invocation accordingly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/publish.yml:
- Around line 47-51: The "Create GitHub release" step runs gh release create
"$TAG_REF" --generate-notes which will fail if a release for TAG_REF already
exists; make the step idempotent by either appending a no-op on failure (e.g.,
add "|| true") or by first checking for an existing release with gh release view
"$TAG_REF" and only calling gh release create when that check fails so the
workflow won't error on re-runs; update the step that sets GH_TOKEN and TAG_REF
and the command invocation accordingly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 61404219-7b75-420d-9900-5e75ddf829b7

📥 Commits

Reviewing files that changed from the base of the PR and between e9186e2 and 4c3b297.

📒 Files selected for processing (1)

• .github/workflows/publish.yml