Migrate release pipeline to changesets (PUBLISHING.md standard)#44
Merged
Migrate release pipeline to changesets (PUBLISHING.md standard)#44
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
Note
|
| Cohort / File(s) | Summary |
|---|---|
Changesets configuration & docs \.changeset/README.md, \.changeset/config.json, \.changeset/release-pipeline-migration.md |
Add Changesets configuration, README explaining usage/bump types/publish process, and a migration release note describing pipeline migration and Zod validation mention. |
PR validation workflow \.github/workflows/changeset.yml |
New CI job that checks PR labels and diffs to ensure a .changeset/*.md (excluding README.md) exists unless skip-changeset label is present; fails PR when missing. |
Publish workflow \.github/workflows/publish.yml |
New publish workflow triggered on pushes to main: checkout, pnpm/Node setup, build, and run changesets/action to version/publish to npm using provided tokens. |
Removed semantic-release config & workflow \.github/workflows/release.yml, \.releaserc.json |
Deletes semantic-release workflow and configuration including commit analysis, changelog rules, npm/git/github integrations, and associated CI steps. |
Package metadata & scripts package.json |
Remove semantic-release-related scripts/devDeps; add @changesets/cli and scripts: changeset, changeset:version, changeset:publish. |
Sequence Diagram(s)
sequenceDiagram
participant Author as PR Author
participant GitHub as GitHub Actions
participant Repo as Repository (git)
participant Changesets as changesets/action
participant NPM as npm Registry
Author->>Repo: Open PR with changes & labels
GitHub->>Repo: Checkout PR/ref and compute diff
GitHub->>Repo: Read PR labels
alt no skip-changeset label
GitHub->>Repo: Search for `.changeset/*.md` (excl README.md)
alt changeset present
GitHub-->>Author: Pass (log changeset paths)
else no changeset
GitHub-->>Author: Fail (request changeset or add skip label)
end
else skip-changeset label present
GitHub-->>Author: Bypass check
end
Note over GitHub,Changesets: On push to main
GitHub->>Repo: Checkout full history
GitHub->>Changesets: Run changesets/action (version & publish)
Changesets->>NPM: Publish packages
Changesets-->>Repo: Commit/version bump commits (if configured)
Estimated code review effort
🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
- feat(ci): semantic-release automated publishing pipeline #22: Introduced the original semantic-release setup that this PR removes and replaces with Changesets-based automation.
- fix(ci): chain release after CI + credential fix for semantic-release #30: Edited the release workflow and credentials for semantic-release; overlaps/conflicts with this PR's removal of that workflow.
- fix(ci): harden release workflow per CodeRabbit review #31: Modified
.github/workflows/release.yml(now deleted by this PR); directly related to the replaced CI flow.
🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 inconclusive)
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Description check | ❓ Inconclusive | The PR description provides context about the migration, identifies the monorepo structure, and references PUBLISHING.md as the source of truth, but appears incomplete (truncated with 'Recovered automatically by Automaker post-agent hook'). | Complete the PR description to ensure it covers all required template sections: type of change, related issue, tests added, and the full checklist of verification steps. |
✅ Passed checks (2 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly describes the main change: migrating the release pipeline from semantic-release to changesets, following the PUBLISHING.md standard. |
| 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
- Post copyable unit tests in a comment
- Commit unit tests in branch
feature/migrate-release-pipeline-to-changesets
📝 Coding Plan
- Generate coding plan for human review comments
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/README.md:
- Around line 1-31: Run Prettier on the Changesets README to fix CI formatting
failures: format the "Changesets" README.md (ensure fenced code blocks, lists,
headings and spacing conform to Prettier rules), save the changes, stage the
updated README.md, and push so CI can re-run; this targets the markdown file
whose top-level heading is "Changesets".
In @.changeset/release-pipeline-migration.md:
- Around line 1-7: Prettier formatting in the changeset was flagged—run prettier
--write on the changeset files (including
".changeset/release-pipeline-migration.md") to fix formatting, then commit the
formatted file; additionally, if you want finer-grained changelog entries, split
the single changeset that currently lists multiple package bumps ("helixir",
"@helixir/core", "@helixir/github-action") and mixed changes into separate
changeset files, each describing one logical change (e.g., one for release
pipeline migration, one for Zod schema validation, one for miscellaneous
tooling/bugfixes) so the changelog entries are distinct.
In @.github/workflows/changeset.yml:
- Around line 1-30: Add an explicit permissions block to the GitHub Actions
workflow named "Changeset Required" (job "changeset", step "Check for
changeset") to declare minimal read-only access; update the top-level of the
workflow to include permissions: contents: read and pull-requests: read so the
job no longer relies on default permissions and documents the least-privilege
intent.
- Around line 18-22: The LABELS extraction and check using echo "$LABELS" | grep
-q "skip-changeset" is fragile because it can match partial label names; update
the check so it only matches an exact label by either parsing LABELS with jq
(e.g., check if any element equals "skip-changeset") or, if avoiding jq, change
the grep usage to enforce exact matching (word boundaries or a JSON-aware
exact-match regex) when evaluating the if condition that references LABELS and
the grep call.
In @.github/workflows/publish.yml:
- Around line 26-28: The workflow pin currently allows any pnpm major >=9 via
the pnpm/action-setup step (the with: version field), which can cause
non-reproducible runs; change the version value to a fixed release or a tighter
constraint (e.g., "9" or a specific patch like "9.15.0") in the
pnpm/action-setup@v4 step so CI always installs a known pnpm version that
matches your package.json engines.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 57a31896-c36f-4f06-b12b-bd078e2b0bd5
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (8)
.changeset/README.md.changeset/config.json.changeset/release-pipeline-migration.md.github/workflows/changeset.yml.github/workflows/publish.yml.github/workflows/release.yml.releaserc.jsonpackage.json
💤 Files with no reviewable changes (2)
- .releaserc.json
- .github/workflows/release.yml
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/release-pipeline-migration.md:
- Line 7: The changeset summary uses the vague phrase "Various tool improvements
and bug fixes" which is not actionable for release notes; replace that phrase in
the .changeset entry with a concise, user-facing bulleted list of the concrete
changes (or split this single changeset into multiple changeset files), e.g.
list the migration from semantic-release, the added Zod schema validation for
design tokens, and each notable tool fix or user-impacting bug by name so the
generated release notes are specific and actionable.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b4009ce3-a0b9-4dd9-b0f9-114d2f4d2525
📒 Files selected for processing (2)
.changeset/README.md.changeset/release-pipeline-migration.md
…abel match, changeset description - Add permissions: contents: read / pull-requests: read to changeset.yml - Use jq exact match for skip-changeset label (prevent partial name collision) - Pin pnpm to '9' in publish.yml (reproducible CI installs) - Replace vague changeset description with specific user-facing bullets Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.changeset/release-pipeline-migration.md (1)
5-5:⚠️ Potential issue | 🟡 MinorChangeset summary is too vague for release notes.
"Various tool improvements and bug fixes" is not actionable for users reading the changelog. Consider either:
- Replacing with specific, user-impacting changes (e.g., list the actual tool improvements and bug fixes)
- Splitting into separate changesets for the release pipeline migration, Zod schema validation, and individual bug fixes
This ensures the generated release notes clearly communicate what changed to end users.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.changeset/release-pipeline-migration.md at line 5, The changeset summary "Migrate release pipeline from semantic-release to changesets. Add Zod schema validation for design token files. Various tool improvements and bug fixes." is too vague for release notes; update this changeset by either expanding the summary to list specific, user-facing tool improvements and the concrete bug fixes (e.g., name the tools changed, specific bugs fixed, and user impact) or split into multiple changesets so one is titled "Migrate release pipeline to changesets," another "Add Zod schema validation for design token files," and separate ones for each distinct bugfix or tooling change; ensure each changeset body contains actionable, user-facing descriptions so generated release notes are clear.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.changeset/config.json:
- Around line 1-11: Update the Changesets schema reference in
.changeset/config.json to track the newer minor releases: replace the explicit
"$schema" value "https://unpkg.com/@changesets/config@3.1.2/schema.json" with
either "https://unpkg.com/@changesets/config@3.1.3/schema.json" or the more
future-proof "https://unpkg.com/@changesets/config@3/schema.json" so the config
(including "changelog", "commit", "access", and "ignore") benefits from current
minor updates.
---
Duplicate comments:
In @.changeset/release-pipeline-migration.md:
- Line 5: The changeset summary "Migrate release pipeline from semantic-release
to changesets. Add Zod schema validation for design token files. Various tool
improvements and bug fixes." is too vague for release notes; update this
changeset by either expanding the summary to list specific, user-facing tool
improvements and the concrete bug fixes (e.g., name the tools changed, specific
bugs fixed, and user impact) or split into multiple changesets so one is titled
"Migrate release pipeline to changesets," another "Add Zod schema validation for
design token files," and separate ones for each distinct bugfix or tooling
change; ensure each changeset body contains actionable, user-facing descriptions
so generated release notes are clear.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b4bc13e3-ebc4-4ff3-a922-b4efa7d9b5db
📒 Files selected for processing (3)
.changeset/README.md.changeset/config.json.changeset/release-pipeline-migration.md
This was referenced Mar 12, 2026
This was referenced Mar 12, 2026
Merged
Merged
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
1 participant
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
Migrate helixir's npm release pipeline from semantic-release to @changesets/cli + changesets/action@v1, following the exact patterns documented in PUBLISHING.md (the org-wide release standard authored by the helix team).
Read PUBLISHING.md in the repo root before starting — it is the source of truth for this migration.
Context
helixir is a MONOREPO with three publishable packages:
helixir(root — the CLI/MCP server, already published at v0.1.0)@helixir/core(packages/core — w...Recovered automatically by Automaker post-agent hook
Summary by CodeRabbit
Chores
Documentation