Release: Semantic Release#207
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughAdds a full pre-release automation pipeline: a new ChangesRelease Automation Pipeline
Repository Metadata
Sequence Diagram(s)sequenceDiagram
participant PR as Merged PR (main)
participant Workflow as pre-release.yml
participant SemanticRelease as semantic-release
participant GitHub as GitHub API
PR->>Workflow: pull_request closed + merged
Workflow->>Workflow: parse PR description for commit type
Workflow->>SemanticRelease: npx semantic-release (creates v1.x.x-main.N tag)
SemanticRelease->>GitHub: create prerelease v1.x.x-main.N
Workflow->>GitHub: GET latest -main.N prerelease
Workflow->>GitHub: GET merged PRs since last stable tag
Workflow->>GitHub: PATCH prerelease notes (grouped changelog)
Workflow->>GitHub: DELETE stale -main.N prereleases + tags
Workflow->>GitHub: ensure released labels exist
Workflow->>GitHub: remove all labels from merged PR
Workflow->>GitHub: add two released labels to merged PR
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
…h4DevAI/kaapi-frontend into feat/semantic-release
|
🎉 This PR is included in version 0.3.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
| ].map(c => ({ ...c, items: [] })); | ||
|
|
||
| const typeOf = (pr) => { | ||
| const m = (pr.body || '').match(/type:\s*(feat|fix|chore|docs|refactor)/i); |
There was a problem hiding this comment.
Just a suggestion: instead of writing the category title (like feat, fix, etc.) in the PR body, we could derive it from the branch name. I think that would keep the PR body cleaner and make the process a bit more streamlined.
There was a problem hiding this comment.
Thanks for this suggestion but I considered this, but I'd prefer to keep the type explicit in the PR rather than derive it from the branch name. Since this is open source, we can't rely on contributors following a feat/, fix/ branch convention (GitHub web edits produce patch-1, and our own team often names branches module-wise like auth/... etc.). Branch names also can't carry mixed types, and they're hard to correct after push. To address the "less manual / cleaner" goal, I'd rather add a PR-description lint (conventional-commit check) so the explicit type is validated automatically.
github-actions
Bot
added
released
released on @main
and removed
ready-for-review
labels
|
🎉 This PR is included in version 0.2.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 0.3.0-main.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
2 participants
Issue: #213
Type
type: feat
Summary
.releaserc.json— semantic-release config. Runs off the main branch and wires up the commit-analyzer, release-notes-generator, and GitHub plugins. Version bumps are mapped from PR type:github/workflows/pre-release.yml— triggered when a PR is merged into main. It extracts the PR type from the description, installs the semantic-release toolchain, generates a conventional commit, runs semantic-release to cut the version/tag and notes, and applies a released label back to the PR.cd-production.yml→create-release.yml— also tightens the tag trigger from'v*'to the stricter semver pattern'v[0-9]+.[0-9]+.[0-9]+'.github/PULL_REQUEST_TEMPLATE.md— restructured with Summary, issue reference, PR type (feat | fix | chore | docs | refactor), and a checklist. The PR type field is what the release workflow reads to determine the version bump.Summary by CodeRabbit
Release Notes
Chores
Other