GitHub release workflow

[dragosv]

Add GitHub Release workflow

Summary

Adds a GitHub Actions workflow that creates a GitHub Release whenever a version tag (v*.*.*) is pushed. The workflow runs the full test suite before publishing and validates that the tag matches the version declared in build.zig.zon.

What changed

Area	Change
.github/workflows/release.yml	New workflow triggered on v*.*.* tags — runs unit + integration tests, validates tag/version consistency, generates release notes, and creates a GitHub Release

Motivation

• Automated releases — pushing a tag is the only manual step; the workflow handles testing, validation, and release creation.
• Version consistency — the tag-vs-build.zig.zon check prevents accidental mismatches between the Git tag and the declared package version.
• Pre-release support — tags containing a hyphen (e.g. v0.2.0-rc1) are automatically marked as pre-releases.

Workflow overview

push tag v*.*.*
  └─► test job (build → unit tests → integration tests)
        └─► release job
              ├─ validate tag matches build.zig.zon version
              ├─ generate release notes from commit history
              └─ create GitHub Release (draft: false, prerelease: auto)

Summary by Sourcery

Build:

• Introduce a release workflow that runs Zig builds and tests on tagged pushes and then creates a GitHub Release with generated notes, validating the tag against build.zig.zon.

[sourcery-ai]

Reviewer's Guide

Adds a GitHub Actions workflow that runs the Zig build + test pipeline on version tags and, if successful, validates the tag against build.zig.zon, generates release notes, and creates a GitHub Release (with automatic prerelease detection).

Flow diagram for release job validation and release creation logic

flowchart TD
    Start["Start release job"]
    Checkout["Checkout repository (fetch-depth: 0)"]
    ExtractTag["Extract TAG from GITHUB_REF (strip prefix refs/tags/v)"]
    ReadZon["Read ZON_VERSION from build.zig.zon via grep"]
    Compare{TAG == ZON_VERSION?}
    ErrorEnd["Fail workflow with error\nTag vTAG does not match build.zig.zon version"]

    PrevTag["Get PREVIOUS_TAG via git describe --tags --abbrev=0 HEAD^"]
    HasPrev{PREVIOUS_TAG found?}
    InitialBody["Set body = 'Initial release.'"]
    BuildNotes["Build body from git log\nPREVIOUS_TAG..HEAD as '- message (sha)' list"]

    CreateRelease["Create GitHub Release via softprops/action-gh-release@v2\n- generate_release_notes: true\n- body: steps.notes.outputs.body\n- draft: false\n- prerelease: contains(github.ref, '-')"]
    End["Release job complete"]

    Start --> Checkout --> ExtractTag --> ReadZon --> Compare
    Compare -- No --> ErrorEnd
    Compare -- Yes --> PrevTag --> HasPrev
    HasPrev -- No --> InitialBody --> CreateRelease --> End
    HasPrev -- Yes --> BuildNotes --> CreateRelease --> End

Loading

File-Level Changes

Change	Details	Files
Introduce a tag-driven GitHub Actions workflow that runs tests on Zig 0.15.2 for v*.. tags and then creates a GitHub Release.	Configure workflow to trigger on pushes of tags matching v*.. and request contents: write permissions. Add a test job that checks out the repository, installs Zig 0.15.2, builds the project, and runs unit and integration tests. Define a release job that depends on tests, re-checks out the repo with full history, validates the pushed tag against the version in build.zig.zon, generates release notes from git history, and invokes softprops/action-gh-release to publish a non-draft release with prerelease flag inferred from the tag.	.github/workflows/release.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Warning

Rate limit exceeded

@dragosv has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 minutes and 37 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0db8c12f-d6f2-48d1-9280-f134706e4b2a

📥 Commits

Reviewing files that changed from the base of the PR and between b7025d4 and 4f4e814.

📒 Files selected for processing (1)

• .github/workflows/release.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch release

---

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

[sourcery-ai]

Hey - I've left some high level feedback:

• The grep -oP '\.version\s*=\s*"\K[^"]+' build.zig.zon parsing is quite brittle and will break on minor formatting changes; consider using a more robust approach (e.g., a small Zig script or a less format-sensitive pattern) to extract the version.
• In the Create GitHub Release step you set generate_release_notes: true while also passing a custom body; since the custom body will override generated notes, consider removing generate_release_notes or dropping the manual notes generation for clarity.
• The git describe --tags --abbrev=0 HEAD^ logic for PREVIOUS_TAG can behave unexpectedly around merge commits or non-linear histories; you may want to base it on the latest tag reachable from HEAD (e.g., git describe --tags --abbrev=0 --always HEAD~1 or a similar strategy) to make release notes generation more predictable.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `grep -oP '\.version\s*=\s*"\K[^"]+' build.zig.zon` parsing is quite brittle and will break on minor formatting changes; consider using a more robust approach (e.g., a small Zig script or a less format-sensitive pattern) to extract the version.
- In the `Create GitHub Release` step you set `generate_release_notes: true` while also passing a custom `body`; since the custom body will override generated notes, consider removing `generate_release_notes` or dropping the manual notes generation for clarity.
- The `git describe --tags --abbrev=0 HEAD^` logic for `PREVIOUS_TAG` can behave unexpectedly around merge commits or non-linear histories; you may want to base it on the latest tag reachable from `HEAD` (e.g., `git describe --tags --abbrev=0 --always HEAD~1` or a similar strategy) to make release notes generation more predictable.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}