Fix release notes to include all PR commits instead of only merge commit

[Copilot]

Release workflow was only parsing the merge commit message (git log -1), omitting all individual commits from PRs.

Changes

• Parse PR commit range: Use git log $baseSha..$headSha to retrieve all commits between PR base and head
• Categorize by type: Parse conventional commit format and group into sections (feat, fix, perf, refactor, docs, test, chore, build, ci, style, revert)
• Structured output: Generate release notes with subsections per commit type, including short hash for each entry

Before/After

Before:

## Changes

**🐛 Fix**: Merge pull request #42 from feature-branch

After:

## Changes

### ✨ Features
- Add process monitoring support (a1b2c3d)
- Implement uptime tracking (e4f5g6h)

### 🐛 Fixes
- Fix memory leak in snapshot logic (i7j8k9l)

### 📝 Documentation
- Update README with build instructions (m0n1o2p)

The workflow now surfaces actual changes rather than merge commit metadata.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>release.yml doesn't show correct commits</issue_title>
<issue_description>while i haven't 100% tested this yet, i'm 99% usre that the release.yml commit parsing is wrong. it uses only the merge commit's name for the feat, perf, refactor etc. parsing, meaning the release only shows the specific merge commits. this means that literally all the commits in the pr aren't even show in the release text
</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes release.yml doesn't show correct commits #50

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Summary by CodeRabbit

• Chores
  • Improved release notes generation to better organize and aggregate changes by type across all pull request commits.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[supervoidcoder]

@coderabbitai review

[coderabbitai]

Walkthrough

Modified release.yml to parse all PR commits from base to head instead of a single commit, categorizing each by conventional-commit type (feat, fix, perf, refactor, docs, test, chore, build, ci, style, revert, others), and generating structured multi-section release notes aggregating commits by category.

Changes

Cohort / File(s)

Summary

Release Notes Generation .github/workflows/release.yml

Replaced single-commit parsing with PR-wide commit collection; introduced categorization loop for conventional-commit types; restructured release notes from single-section to multi-section format (Features, Fixes, Performance, Refactoring, etc.) with bullet aggregations; changed footer to reference PR base/head SHAs instead of single commit SHA; switched to delimiter-based GitHub Actions output for consolidated payload

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• #14: Adds conventional-commit parsing for release notes generation; modifies the same .github/workflows/release.yml file with similar commit categorization logic.

Suggested labels

enhancement, ci/cd

Poem

🐰 hops with delight
All commits now dance in the light,
No more hiding, categorized right—
Feat, fix, and docs take their flight,
Release notes bloom, oh what a sight! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and clearly summarizes the main change: fixing release notes to include all PR commits instead of only the merge commit.
Linked Issues check	✅ Passed	The PR fully addresses issue #50 by implementing parsing of all PR commits via git log range and categorizing them by conventional commit types into structured release notes sections.
Out of Scope Changes check	✅ Passed	All changes in the workflow file are directly related to fixing the release notes commit parsing, with no unrelated modifications detected.
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.}

---

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

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[supervoidcoder]

great jjob just tiny nitpick

[supervoidcoder]

Suggested change

	$releaseNotes += "### 💄 Style`n"
	$releaseNotes += "### 🎨 Style`n"

the lipstick emoji ticks me off lolllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll

[supervoidcoder]

@coderabbitai which other emojis you suggest for style?

[coderabbitai]

@supervoidcoder, here are some popular emoji alternatives for the Style category:

Most Common Choice:

• 🎨 :art: - Artist Palette - This is the standard in gitmoji and widely used for formatting/style changes

Other Good Options:

• 🧹 :broom: - Broom (your suggestion!) - Great for "cleaning up" code
• 🖌️ :paintbrush: - Paintbrush - Similar vibe to the palette
• 📐 :triangular_ruler: - Triangular Ruler - Emphasizes alignment/formatting
• 📏 :straight_ruler: - Straight Ruler - Also works for formatting
• 🧼 :soap: - Soap - Cleaning/tidying up code

My recommendation: Go with 🎨 (artist palette) as it's the most recognized in the developer community for style/formatting commits, or stick with your 🧹 (broom) suggestion if you prefer the "cleaning up code" metaphor!

🐰✨

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

[supervoidcoder]

ok great i did the palette

[coderabbitai]

@supervoidcoder Awesome! 🎨 is a solid choice – it's the standard for style/formatting changes across the dev community. Your release notes will look great!

🐰✨

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

---

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!