feat(release): add release.yml triggered on SemVer tags (epic 005 T008)

[owkwo-bot]

Summary

• Adds .github/workflows/release.yml, triggered on v[0-9]* tag pushes (epic 005, Phase 4 US2, T008).
• Its only real step calls validate-release-tag.sh (T005) against the pushed tag — fails fast on a tag/version mismatch before any build/package work exists.
• Intentionally minimal: build, packaging, checksums, and atomic release creation are separate follow-up tasks (T009-T012), not in scope here.

Test plan

• YAML parses (Ruby Psych, no pyyaml available locally)
• validate-release-tag.sh re-run manually against this repo's real Cargo.toml version for both a matching and mismatched tag — already covered by its own fixture tests from T005
• make build / make test green
• Self-review pass (pr-review-toolkit:code-reviewer) — no blocking issues; confirmed GITHUB_REF_NAME plain env-var usage avoids the ${{ }}-template shell-injection footgun, and action pinning matches ci.yml's convention

🧙 Built with WOZCODE

Summary by Sourcery

Add a minimal GitHub Actions release workflow triggered by SemVer tag pushes that only validates the release tag against the workspace version as the first phase of the release pipeline.

CI:

• Introduce .github/workflows/release.yml triggered on v[0-9]* tag pushes with least-privilege permissions and pinned checkout action for future release creation.

Chores:

• Mark US2 Task T008 as completed in the CI/release versioning spec with notes on the implemented release validation workflow scope.

---

Summary by cubic

Validates SemVer tag pushes with a new release workflow. Previously tag pushes did nothing; now the job fails fast on a tag/version mismatch and stops before any build or release work.

• Triggers on tags matching v[0-9]*.
• Runs .github/scripts/validate-release-tag.sh with GITHUB_REF_NAME.
• Pins actions/checkout with fetch-depth: 0 and persist-credentials: false.
• Sets least-privilege permissions: contents: read only; write is deferred to the release-creation step in T012.
• Satisfies epic 005 T008.

Rollout

• Tag releases as vX.Y.Z matching the workspace version in Cargo.toml; mismatches fail the job and stop further steps.

^{Written for commit 4d2c1ec. Summary will update on new commits.}

[sourcery-ai]

Reviewer's Guide

Adds a minimal GitHub Actions release workflow triggered by SemVer-like tags, wired to validate the tag against the workspace version, and marks task T008 as completed in the CI/release specs.

Sequence diagram for SemVer-tag-triggered release validation workflow

sequenceDiagram
  actor Developer
  participant GitHub
  participant Release_workflow
  participant actions_checkout
  participant validate_release_tag_sh

  Developer->>GitHub: push tag v1_2_3 (matches v[0-9]*)
  GitHub->>Release_workflow: trigger push_tags_v[0-9]*
  Release_workflow->>actions_checkout: actions_checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
  actions_checkout-->>Release_workflow: workspace checked_out (fetch_depth_0, persist_credentials_false)
  Release_workflow->>validate_release_tag_sh: validate-release-tag.sh GITHUB_REF_NAME
  alt [tag matches workspace version]
    validate_release_tag_sh-->>Release_workflow: success
  else [tag mismatches workspace version]
    validate_release_tag_sh-->>Release_workflow: failure (fail_fast)
  end

Loading

File-Level Changes

Change	Details	Files
Introduce a minimal GitHub Actions release workflow that runs on SemVer-style tag pushes and validates the tag against the workspace version.	Add a new Release workflow triggered on push tags matching the pattern v[0-9]* Configure least-privilege permissions with contents: write only Use pinned actions/checkout with full history via fetch-depth: 0 and disabled credential persistence Run validate-release-tag.sh with GITHUB_REF_NAME passed as a plain shell argument to avoid template-based shell injection risks	.github/workflows/release.yml
Update CI/release versioning specs to mark the release workflow task as completed and document the implemented behavior.	Mark task T008 as completed in the implementation plan Document the trigger pattern, permissions, checkout configuration, and validation behavior of the new release workflow Clarify that build, packaging, checksums, and atomic release creation remain future tasks (T009-T012)	specs/005-ci-release-versioning/tasks.md

---

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.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[coderabbitai]

Warning

Review limit reached

@rsenna, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 65 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 01b17ed2-296c-4a44-8130-65b7a8b00461

📥 Commits

Reviewing files that changed from the base of the PR and between 8f902e8 and 4d2c1ec.

📒 Files selected for processing (2)

• .github/workflows/release.yml
• specs/005-ci-release-versioning/tasks.md

---

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

[sourcery-ai]

Hey - I've left some high level feedback:

• Since this phase only validates the tag and doesn’t create releases yet, you can tighten the workflow permissions to contents: read and defer contents: write until the release-creation steps are added.
• If you want stricter SemVer enforcement on triggers, consider narrowing the tag pattern from v[0-9]* to something like v[0-9]+.[0-9]+.[0-9]+* so non-SemVer tags don’t invoke the release workflow.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Since this phase only validates the tag and doesn’t create releases yet, you can tighten the workflow permissions to `contents: read` and defer `contents: write` until the release-creation steps are added.
- If you want stricter SemVer enforcement on triggers, consider narrowing the tag pattern from `v[0-9]*` to something like `v[0-9]+.[0-9]+.[0-9]+*` so non-SemVer tags don’t invoke the release workflow.

---

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

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[owkwo-bot]

Since this phase only validates the tag and doesn't create releases yet, you can tighten the workflow permissions to contents: read...

Agreed, fixed in 4d2c1ec.

If you want stricter SemVer enforcement on triggers, consider narrowing the tag pattern from v[0-9]* to something like v[0-9]+.[0-9]+.[0-9]+*...

Declining this one: GitHub Actions tag/branch filters use glob syntax, not regex — + isn't a quantifier there, it's a literal character. v[0-9]+.[0-9]+.[0-9]+* would actually match things like v1+2+3+anything, not stricter SemVer. The current v[0-9]* trigger is intentionally loose — malformed tags (e.g. v1.2) still fire the workflow and fail loudly via validate-release-tag.sh's strict regex check, rather than being silently ignored by a stricter trigger glob. Tightening the trigger would just move the failure mode from "loud validation error" to "nothing happens, tag is silently ignored," which is worse for a release gate.