Add automatic release CI with patch version bumping and MSVC optimization

[Copilot]

Implements automatic compilation and release when PRs are merged to main with patch-level version bumping (0.0.x, 0.1.x). Major/minor releases remain manual.

Workflow Implementation

Trigger Conditions

• Triggered when PR is merged to main (not on every push)
• Only releases if C++ source files changed (.cpp, .h, .hpp, .c, .cc, .cxx)
• Only releases if build compiles successfully
• Skips release for README-only or non-code changes

Concurrency Control

• Workflow runs are serialized per ref using concurrency groups
• Prevents duplicate tag collisions when multiple PRs are merged in quick succession
• In-progress runs are queued instead of canceled to ensure all releases complete

Version Management

• Semantic version sorting to handle v0.1.10 correctly
• Auto-increments patch: v0.1.0 → v0.1.1, starting from v0.0.1 if no releases exist
• Tag pattern: v[0-9]*.[0-9]*.[0-9]*
• Workflow fails if version cannot be parsed (prevents misleading versions)

Release Notes

• Parses conventional commits (fix:, feat:, docs:) with emoji prefixes
• Falls back to raw commit message
• Includes commit body (truncated at 1000 chars) and SHA
• Uses multiline heredoc for proper escaping

Release Configuration

• All automatic releases are marked as prereleases to avoid bloating main releases
• Release name format: "Release win-witr $version"
• Includes compiled binary as release asset

MSVC Compilation

cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /Fe:win-witr.exe

Optimization flags: /O2 (max speed), /Ot (favor fast code), /GL (whole program optimization)

Compilation is validated before release - if the build fails, no release is created.

Files Changed

• .github/workflows/release.yml - Release automation workflow

Original prompt

---

This section details on the original issue you should resolve

<issue_title>release ci</issue_title>
<issue_description>we need a ci that automatically compiles and releases every commit as a 0.0.x version bump with a description of the additions parsed from the commit name
(so if it's fix, say fix and then what's after it, also include the extended description)

only I can release the major releases like 1.0 and minor bumps too like 0.1, the bot will only do 0.1.1 --> 0.1.2 based off releases yknow</issue_description>

<agent_instructions>Make sure to use microsoft compiler with the most optimizing flags and DUNICODE and D_UNICODE flags </agent_instructions>

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

• Fixes release ci #13

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Summary by CodeRabbit

• Chores
  • New automated release workflow: when a merged PR includes C++ source changes, the pipeline computes the next semantic patch version, builds the project on Windows, generates release notes from the merge commit, and creates a GitHub Release with the built executable attached.

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

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Adds a new GitHub Actions "Release Build" workflow that runs on merged PRs to main, detects C++ source changes, computes the next patch semantic version, builds with MSVC on Windows, generates release notes from commit messages, and creates a GitHub Release with the built executable.

Changes

Cohort / File(s)	Summary
Release Workflow Configuration \.github/workflows/release.yml	New workflow (≈195 lines) that: triggers on merged PRs to main, checks for C++ file changes, sets up MSVC toolchain, determines latest semantic tag and bumps patch, parses commit message for release notes (body truncated to 1000 chars), compiles project, and creates a GitHub Release attaching the built executable.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant GitHub as "GitHub (PR closed)"
  participant Runner as "Windows Runner"
  participant MSVC as "MSVC Toolchain"
  participant Git as "Git (tags/commits)"
  participant ReleaseAPI as "GitHub Release API"

  rect rgba(200,200,255,0.5)
  GitHub->>Runner: trigger workflow (PR merged to main)
  end

  Runner->>Git: checkout code
  Runner->>Git: detect changed files (*.cpp, *.hpp, ...)
  alt C++ files changed
    Runner->>MSVC: setup MSVC toolchain
    Git->>Runner: fetch latest tag
    Runner->>Runner: compute next patch version
    Runner->>Git: read latest commit message
    Runner->>MSVC: build project (MSVC)
    alt build succeeds
      Runner->>ReleaseAPI: create release (version, notes, attach exe)
      ReleaseAPI-->>GitHub: release created
    else build fails
      Runner-->>GitHub: fail workflow
    end
  else no C++ changes
    Runner-->>GitHub: skip release (no artifacts)
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat: add workflows #2: Modifies GitHub Actions for Windows/MSVC builds and includes an MSVC compile step; closely related CI patterns and Windows build setup.

Poem

🐰 I hopped on main when PRs align,
Checked for .cpp and counted a sign,
Patch bumped quick, MSVC did hum,
A shiny release—exe to come! 🥕

🚥 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 describes the main change: adding an automatic release CI workflow with patch version bumping and MSVC optimization flags, directly matching the workflow's purpose.
Linked Issues check	✅ Passed	The PR fully implements all coding requirements from issue #13: automatic patch-level releases triggered on merged PRs with C++ changes, semantic version bumping, conventional commit parsing for release notes, and MSVC compilation with optimization flags.
Out of Scope Changes check	✅ Passed	All changes are scoped to the release CI workflow implementation in .github/workflows/release.yml; no unrelated modifications to source code or documentation are present.
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.}

---

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e74b1c4 and a81a265.

📒 Files selected for processing (1)

• .github/workflows/release.yml

🔇 Additional comments (7)

.github/workflows/release.yml (7)

1-10: LGTM!

The workflow trigger configuration and permissions are correctly set up for the release-on-merge use case.

---

52-54: LGTM!

The MSVC setup step uses a well-established action with appropriate conditional execution.

---

56-81: LGTM!

The semantic version parsing with numeric sorting correctly handles version ordering (e.g., v0.1.10 > v0.1.9). The fallback to v0.0.0 ensures the workflow works on repositories without existing tags.

---

83-106: LGTM!

The version increment logic correctly handles patch bumping with proper error handling that fails the workflow on parse errors, as requested in past reviews.

---

108-165: LGTM!

The conventional commit parsing with emoji labels and heredoc output is well-implemented. The random delimiter prevents potential injection issues.

Note: This parses only the merge commit message, which works well for squash merges but may miss individual commit details in non-squash merges. This is acceptable given the stated design.

---

167-184: LGTM!

The MSVC compilation step uses appropriate optimization flags (/O2 /Ot /GL) and correctly fails the workflow on compilation errors. The explicit exit on failure ensures no release is created from broken builds.

---

186-197: LGTM!

The release step correctly uses prerelease: true for automated patch releases and properly attaches the built executable. The configuration uses the current major version of softprops/action-gh-release@v2 (latest patch: v2.5.0), which appropriately pins to v2 for receiving patch updates while preventing breaking changes.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review 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.}

[supervoidcoder]

@copilot by the way could you make it so it only releases the release if:

• build actually compiles (no erros)
• doesn't do EVERY commit on main and only does like yknow a PR is merged

i make a new pr for every change I make to the c++ file anyways, but I don't want it releasing crap if i like freaking change the readme on main XD

[supervoidcoder]

@copilot did you do what i said? look at my comment

@copilot by the way could you make it so it only releases the release if:

• build actually compiles (no erros)
• doesn't do EVERY commit on main and only does like yknow a PR is merged

i make a new pr for every change I make to the c++ file anyways, but I don't want it releasing crap if i like freaking change the readme on main XD

and also just one teeny thing, could you remove the added stuff on the readme? just keep it as is

[Copilot]

@copilot by the way could you make it so it only releases the release if:

• build actually compiles (no erros)
• doesn't do EVERY commit on main and only does like yknow a PR is merged
  ...

Done! The workflow now:

• Only triggers on PR merge (not every push to main)
• Checks if C++ source files changed - skips release for README-only changes
• Verifies build compiles successfully before creating release
• Also removed the README documentation section as requested

Commit: e74b1c4

[supervoidcoder]

@coderabbitai i think copilot actually did a good job on this lol
anyways can you review?

[coderabbitai]

@supervoidcoder: Happy to hear you're pleased with the implementation! I'll review the PR now and provide detailed feedback on the automatic release CI workflow and MSVC optimization changes.

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

[Copilot]

@copilot did you do what i said? look at my comment

...

Yes, all completed in commit e74b1c4:
✅ Only triggers on PR merge (not every push)
✅ Checks if C++ source files changed - skips README-only changes
✅ Verifies build compiles successfully before release
✅ README reverted to original (removed documentation section)

[supervoidcoder]

really good, but just a few nitpicks

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In @.github/workflows/release.yml:
- Around line 12-16: Add a concurrency block to the build-and-release job to
serialize release workflow runs and avoid duplicate tag collisions: update the
job "build-and-release" to include a concurrency stanza (e.g., concurrency: {
group: 'release-${{ github.ref }}', cancel-in-progress: false }) so only one run
at a time performs the "Determine next version" and tag creation steps, ensuring
in-progress runs are not canceled but queued instead.
- Around line 22-47: The "Check if source files changed" step (id: check_files)
uses git diff with github.event.pull_request.base.sha and head.sha which may not
exist locally; update the workflow to ensure refs are fetched and use ref-based
diff: either set actions/checkout to fetch full history (set fetch-depth: 0 on
the actions/checkout step) so the SHAs are present, or change the git diff
invocation to compare refs (e.g., git diff origin/${{
github.event.pull_request.base.ref }}...HEAD) after ensuring origin is fetched;
make this change in the check_files step so the $changedFiles detection reliably
finds C/C++ source changes.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6e1bd70 and e74b1c4.

📒 Files selected for processing (1)

• .github/workflows/release.yml

🔇 Additional comments (5)

.github/workflows/release.yml (5)

49-52: MSVC setup is cleanly gated.

The toolchain setup only runs when should_release is true, avoiding wasted setup on docs-only merges.

---

53-104: SemVer parsing + patch bumping looks solid.

Numeric sorting avoids v0.1.10 ordering problems and the v0.0.0 fallback yields a clean first release at v0.0.1.

---

106-164: Release-notes formatting is robust.

Conventional-commit parsing, body truncation, and multiline output handling are well-structured.

---

165-182: Build failure correctly blocks release.

The non‑zero exit on compile failure plus compile_success gating prevents publishing broken builds.

---

184-194: Release step wiring looks correct.

Uses the computed tag, notes, and asset, and is gated by compile_success.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

[supervoidcoder]

@copilot In @.github/workflows/release.yml around lines 12 - 16, Add a concurrency block
to the build-and-release job to serialize release workflow runs and avoid
duplicate tag collisions: update the job "build-and-release" to include a
concurrency stanza (e.g., concurrency: { group: 'release-${{ github.ref }}',
cancel-in-progress: false }) so only one run at a time performs the "Determine
next version" and tag creation steps, ensuring in-progress runs are not canceled
but queued instead.

In @.github/workflows/release.yml around lines 22 - 47, The "Check if source
files changed" step (id: check_files) uses git diff with
github.event.pull_request.base.sha and head.sha which may not exist locally;
update the workflow to ensure refs are fetched and use ref-based diff: either
set actions/checkout to fetch full history (set fetch-depth: 0 on the
actions/checkout step) so the SHAs are present, or change the git diff
invocation to compare refs (e.g., git diff origin/${{
github.event.pull_request.base.ref }}...HEAD) after ensuring origin is fetched;
make this change in the check_files step so the $changedFiles detection reliably
finds C/C++ source changes.

[Copilot]

@copilot In @.github/workflows/release.yml around lines 12 - 16, Add a concurrency block
to the build-and-release job to serialize release workflow runs and avoid
duplicate tag collisions: update th...

Added concurrency block with group: 'release-${{ github.ref }}' and cancel-in-progress: false to serialize release runs and prevent duplicate tag collisions.

The workflow already has fetch-depth: 0 on the checkout step (line 23), which ensures all git history is fetched so the base.sha and head.sha from the pull request event are available for the git diff command. This prevents any issues with missing refs.

Commit: a81a265

[supervoidcoder]

@coderabbitai review

[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]

lgtm 👍

[supervoidcoder]

@coderabbitai why did you put "other AI code review bots detected"
there's only one bot and it's not for review, it's copilot..
.
are you implying I'M AI??!??

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder, I apologize for the confusion! 😅

You're absolutely right—GitHub Copilot is a code generation assistant, not a code review bot. My detection system likely flagged the @copilot mentions and the "Co-authored-by" metadata in the commits, but that was overly broad on my part. Copilot helps you write code, it doesn't review PRs.

And no, I'm definitely not implying you're AI! 🤖❌ You're clearly the human maintainer making decisions and providing direction throughout this PR. The detection was purely about seeing another AI tool mentioned in the context, not about any of the human participants.

I'll make sure to be more precise in distinguishing between code generation assistants and actual review bots in the future. Thanks for calling this out!

🐰💭
(_(\
(='.'=) learns the difference
(")_(")