[silverbucket]

Problem

Release failed pushing the Makefile bump directly to master:

• Required status check test expected
• Changes must be made through a pull request

Solution

• Current version = latest published GitHub release tag (e.g. v1.3.0 → 1.3.0); Makefile only if no releases yet
• Bump dropdown unchanged: patch (default) / minor / major
• Publish from current master (no push to master)
• After publish: open chore/bump-version-X.Y.Z PR to sync the Makefile; enable auto-merge when the repo allows it

After merge

Run Actions → Release with patch to publish v1.3.1 (from latest v1.3.0). Merge the follow-up Makefile PR when it appears.

  

Summary by CodeRabbit

• Chores

  • Updated release workflow to compute versions from the latest published release tag instead of the Makefile.
  • Release workflow now creates a pull request for Makefile updates instead of directly committing to the main branch.

• Documentation

  • Updated release instructions to reflect the new release process workflow.

[coderabbitai]

📝 Walkthrough

Walkthrough

The Release GitHub Actions workflow is refactored to compute the next version from the latest published GitHub release tag and to synchronize the Makefile via an automated pull request instead of direct commits to master. The workflow gains pull-requests: write permission, and the documentation is updated accordingly.

Changes

Release Workflow Refactoring

Layer / File(s)	Summary
Workflow input and permission updates .github/workflows/release.yml	The bump input description is updated to reflect bumping from the latest published release tag. The workflow gains pull-requests: write permission to enable pull request creation and auto-merge.
Version discovery from GitHub releases .github/workflows/release.yml	The "Compute release version" step now fetches the latest published release tag via GitHub CLI, with a fallback to parsing the Makefile when no releases exist. Version validation and computation logic is updated. An obsolete Makefile VERSION console log is removed.
Makefile synchronization via pull request .github/workflows/release.yml	The step that directly bumped Makefile on master is removed. A new post-release step creates a dedicated branch, updates Makefile with the computed version, commits and pushes the change, creates a pull request to master, and attempts auto-merge (with fallback instructions if auto-merge is unavailable).
Release workflow documentation README.md	The "Cut a release" section is expanded to document the new workflow: explicitly listing steps for selecting bump type, clarifying that CI derives the next version from the latest published release, and adding a step to merge the automated Makefile bump pull request.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• silverbucket/dwatch#13: Both PRs modify the Release workflow's version computation and Makefile-bumping behavior—the related PR computes from Makefile while this one computes from latest GitHub release and synchronizes via PR.
• silverbucket/dwatch#11: Both PRs update the Release workflow's version tag logic; this PR extends the workflow to compute from the latest release and open a Makefile sync PR.

Suggested labels

ci

Poem

🐰 From master branch to pull request flow,
The release workflow learns to let PRs grow,
GitHub tags now guide the version way,
Makefile syncs through review each day! 🚀

🚥 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: updating the release workflow to respect protected master by creating a PR instead of pushing directly.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch cursor/release-protected-master-91b9

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Security review complete: no medium, high, or critical vulnerabilities found in the changed release workflow or README instructions.

Validated controls: workflow_dispatch input is constrained to the bump choices, release-derived tag data is reduced to X.Y.Z before reaching shell, git, release, and PR sinks, and the job remains behind the release environment while avoiding direct pushes to protected master. No prior automation review threads were present to re-report.

  

_{Sent by Cursor Automation: Find vulnerabilities}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/release.yml (1)

84-93: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

The Makefile sync path is not retryable after a partial post-release failure.

Once the release is published, any transient failure in Lines 146-159 leaves Makefile unsynced, and a rerun will stop at Lines 90-92 before it can recreate or finish the PR. That means the exact failure mode this PR is trying to automate still needs manual repair.

A safer shape here is to make the sync phase independently rerunnable: either split it into a release-triggered follow-up workflow, or let the “release already exists” case continue into an idempotent PR reconciliation path instead of exiting immediately.

Also applies to: 134-159

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 84 - 93, The current "Check
release does not exist" step exits when gh release view finds an existing TAG,
which prevents rerunning the Makefile sync path after a partial post-release
failure; change the workflow so that this step does NOT abort on an existing
release but instead sets a flag (e.g., export RELEASE_EXISTS=true) or writes a
status file and allows the job to continue into an idempotent
PR-reconciliation/sync path, or alternatively move the Makefile sync steps into
a separate release-triggered follow-up workflow that runs on published release
events; update the logic around the gh release view invocation (and anywhere it
currently exits on existence) to be non-fatal and to drive an idempotent sync
routine for the Makefile.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In @.github/workflows/release.yml:
- Around line 84-93: The current "Check release does not exist" step exits when
gh release view finds an existing TAG, which prevents rerunning the Makefile
sync path after a partial post-release failure; change the workflow so that this
step does NOT abort on an existing release but instead sets a flag (e.g., export
RELEASE_EXISTS=true) or writes a status file and allows the job to continue into
an idempotent PR-reconciliation/sync path, or alternatively move the Makefile
sync steps into a separate release-triggered follow-up workflow that runs on
published release events; update the logic around the gh release view invocation
(and anywhere it currently exits on existence) to be non-fatal and to drive an
idempotent sync routine for the Makefile.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d6052b3e-ef79-48eb-9728-4cf6232ff4b6

📥 Commits

Reviewing files that changed from the base of the PR and between 4914449 and e331bb0.

📒 Files selected for processing (2)

• .github/workflows/release.yml
• README.md