ci(release): publish on version-bump merges to main + release 0.3.0

[NikhilVerma]

What

1. Merge-triggered publishing — release.yml now also runs on pushes to main that touch package.json. Merging a version-bump PR publishes to npm automatically via the existing OIDC Trusted Publishing setup; no manual v* tag needed (tags and manual dispatch still work). Merges that touch package.json without bumping the version are no-ops thanks to the already-published guard.
2. Release 0.3.0 — minor bump covering everything since 0.2.0:
   • Added: config-file multi-source sync with selectors + date filtering (feat: config-file multi-source sync with selectors and date filtering #4, @crimsonsunset), incremental pull (feat(sync): incremental pull — fetch only changed pages #6)
   • Fixed: table-cell backslash escaping, loud failure on dropped Notion child-block appends, Bun file I/O in local/scan.ts
   • Also cuts the CHANGELOG for 0.2.0, which shipped with everything under [Unreleased].

Why together

Merging this PR is the end-to-end test: the new trigger fires on this very merge and should publish notion-rsync@0.3.0 with provenance.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 37 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: dbd4f65e-1dbd-4b89-9bc6-6914ba055e71

📥 Commits

Reviewing files that changed from the base of the PR and between 5f1c8ca and 1e0c571.

📒 Files selected for processing (3)

• .github/workflows/release.yml
• CHANGELOG.md
• package.json

Summary by CodeRabbit

• New Release

  • Version 0.2.1 is now available.

• Bug Fixes

  • Improved table-cell escaping.
  • Made appending content to Notion safer.
  • Fixed file input/output handling in Bun environments.

• Chores

  • Updated release automation to publish version updates from the main branch while avoiding duplicate releases.
  • Added detailed release notes for version 0.2.1.

Walkthrough

The package version was incremented from 0.2.0 to 0.2.1. The changelog now documents the 0.2.1 release and identifies 0.2.0 as the previous release. The release workflow now triggers when package.json changes reach main and permits publishing for main pushes, version tags, and manual runs.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the release workflow change, although its stated 0.3.0 release conflicts with the 0.2.1 version bump.
Description check	✅ Passed	The description directly explains the release workflow, version bump, and changelog changes, despite containing version and scope inconsistencies.

---

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

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

78-81: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Pin the Bun runtime for automatic releases.

The verify and publish jobs use oven-sh/setup-bun@v2 without bun-version or bun-version-file. The action falls back to latest when package.json has no Bun pin. A moving runtime can change dependency resolution or build output. Add one shared Bun version file and assert the same bun --version in both jobs. (github.com)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 78 - 81, Pin the Bun runtime used
by both the verify and publish jobs in the release workflow: add one shared Bun
version file, configure each oven-sh/setup-bun@v2 step with bun-version-file,
and add matching bun --version assertions in both jobs to ensure they use the
pinned runtime.

Source: MCP tools

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release.yml:
- Around line 27-28: Gate the main publish workflow on an actual package version
change by comparing package.json.version with the version from
github.event.before before publishing. In .github/workflows/release.yml lines
27-28, add this version-difference condition; in lines 3-4, describe the trigger
as any package.json change until the gate is present; in CHANGELOG.md lines
20-23, retain the no-op claim only once the version-difference gate is enforced.
- Around line 78-81: Update the release workflow’s publish logic so pushes to
refs/heads/main publish with npm tag next, while version-tag releases continue
publishing to latest. Add a manual workflow_dispatch promotion path that runs
npm dist-tag add notion-rsync@<version> latest, and ensure it can promote
versions already published under next without being blocked by the existing
version guard.
- Around line 78-81: Update the release workflow’s Node.js setup to use a tested
Node.js version of 22.14.0 or later, and pin npm to a tested 11.5.1 or later
version before the npm publish step. Preserve the existing publish conditions
and workflow behavior.

---

Nitpick comments:
In @.github/workflows/release.yml:
- Around line 78-81: Pin the Bun runtime used by both the verify and publish
jobs in the release workflow: add one shared Bun version file, configure each
oven-sh/setup-bun@v2 step with bun-version-file, and add matching bun --version
assertions in both jobs to ensure they use the pinned runtime.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 93a340eb-e22b-440d-9aa7-face8b333d5d

📥 Commits

Reviewing files that changed from the base of the PR and between 6d8e16c and 5f1c8ca.

📒 Files selected for processing (3)

• .github/workflows/release.yml
• CHANGELOG.md
• package.json