Make the release workflow work with the master branch protection

[Pierre-Gilles]

Description

Follow-up to #2753. The workflow it added could not actually run a release: pushing the version commit to master failed with GH006, because the branch requires a pull request and 6 status checks, and github-actions[bot] has no bypass.

Having the workflow open that pull request itself does not solve it either — GitHub does not run checks on a pull request created with the GITHUB_TOKEN, so it would stay blocked on the required checks forever. A one-click release would need an identity allowed to bypass the protection (a GitHub App token or an admin PAT). Instead, this splits the release in two so it works with the protection as it stands, and with no secret to configure.

prepare-release.yml — manual dispatch, patch or minor. Bumps the version with npm version --no-git-tag-version, commits it on a release/vX.Y.Z branch, pushes that branch, and links to the pull request to open from the job summary. Because a human opens it, the required checks run — so the release commit is tested before it is tagged.

create-release-tag.yml — now triggered by a push on master touching package.json. It reads the version, and if no matching tag exists, creates vX.Y.Z and dispatches the production images, demo website and apidoc builds. Tags are not covered by the branch protection, so the GITHUB_TOKEN is enough. It is idempotent: a package.json change without a version bump does nothing.

Side effect worth noting: this also covers the current manual process. A bump commit pushed by hand to master now gets tagged and released automatically, without going through prepare-release.

The explicit dispatch of the downstream builds is kept from #2753: a tag pushed with the GITHUB_TOKEN does not trigger workflows listening on push: tags, and workflow_dispatch is one of the two events GitHub does start from that token.

Forum

N/A

Checklist

• Tests pass — no application code changed, only GitHub Actions workflows
• Linter and prettier pass on both front and server — no front or server file changed
• No undocumented breaking change

---

Generated by Claude Code

Summary by CodeRabbit

• New Features
  • Added a guided release-preparation workflow supporting patch and minor releases.
  • Release preparation now creates a dedicated release branch and provides clear next steps and release details.
• Bug Fixes
  • Prevented duplicate release tags from being created.
  • Automated release tagging now uses the package version and skips tags that already exist.
• Chores
  • Improved release automation with safer validation, serialized runs, and clearer status summaries.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 41 seconds

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

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: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: af310e4f-307c-4ad5-a65a-1bf2ed637eac

📥 Commits

Reviewing files that changed from the base of the PR and between 391ce40 and 014039b.

📒 Files selected for processing (2)

• .github/workflows/create-release-tag.yml
• .github/workflows/prepare-release.yml

📝 Walkthrough

Walkthrough

Changes

Release automation

Layer / File(s)	Summary
Prepare release branch .github/workflows/prepare-release.yml	Adds manual patch or minor version preparation. The workflow validates master, updates package versions, creates and pushes a release branch, and reports PR metadata.
Create release tag .github/workflows/create-release-tag.yml	Runs on package.json changes on master. It reads the package version and creates an annotated tag when the tag does not already exist.
Dispatch release workflows .github/workflows/create-release-tag.yml	Dispatches downstream release workflows with the new tag and writes a conditional job summary.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Maintainer
  participant PrepareRelease
  participant Master
  participant CreateReleaseTag
  participant ReleaseWorkflows

  Maintainer->>PrepareRelease: Select patch or minor release
  PrepareRelease->>Master: Push release branch and version commit
  Master->>CreateReleaseTag: Merge package.json change
  CreateReleaseTag->>CreateReleaseTag: Check for existing version tag
  CreateReleaseTag->>ReleaseWorkflows: Dispatch workflows with new tag

Loading

Possibly related PRs

• GladysAssistant/Gladys#2753: Both changes update release tagging automation and move version bumping into a preparation workflow.

Poem

A rabbit checks the version line,
Then hops a branch into the pine.
A tag is stamped when none is found,
Release workflows race around.
“Clean hops!” I cheer, “the flow is bright!”

🚥 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 clearly describes the main change: updating the release workflow to work with master branch protection.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/github-action-release-tag-ht845u

---

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

[github-actions]

🐳 A Docker image has been built for this branch and pushed to the GitHub Container Registry.

You can test this pull request (AMD64 only) by pulling the image below:

ghcr.io/gladysassistant/gladys-preview:claude-github-action-release-tag-ht845u

For example, run it with:

sudo docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --cgroupns=host \
  --restart=always \
  --privileged \
  --network=host \
  --name gladys-claude-github-action-release-tag-ht845u \
  -e NODE_ENV=production \
  -e SERVER_PORT=80 \
  -e TZ=Europe/Paris \
  -e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /var/lib/gladysassistant:/var/lib/gladysassistant \
  -v /dev:/dev \
  -v /run/udev:/run/udev:ro \
  ghcr.io/gladysassistant/gladys-preview:claude-github-action-release-tag-ht845u

This comment and the image are automatically updated on every new commit pushed to this pull request.

Need an ARM64 image (Raspberry Pi, Apple Silicon, …)? Comment /build-arm64 on this pull request.

[coderabbitai]

Actionable comments posted: 1

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

Inline comments:
In @.github/workflows/create-release-tag.yml:
- Around line 54-68: Update the release dispatch step around the workflow loop
to recover when an individual gh workflow run fails after the tag is created,
ensuring later workflows still run and incomplete dispatches can be retried. Add
an explicit manual retry path for the existing tag, or persist per-workflow
dispatch state and retry only failed workflows; keep normal push runs from
dispatching every existing tag.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38acd752-a4e3-42e9-86e2-36991fee8dbc

📥 Commits

Reviewing files that changed from the base of the PR and between 68910d6 and 391ce40.

📒 Files selected for processing (2)

• .github/workflows/create-release-tag.yml
• .github/workflows/prepare-release.yml

[cursor]

Stale comment

The two-step release flow is a clear fix for the GH006 / branch-protection problem from #2753, and the "human opens the PR so checks actually run" constraint is documented well.

I am not approving yet: create-release-tag has a recovery footgun on the production release path (tag pushed, downstream dispatch fails → re-run becomes a no-op). Details inline.

Also labeling risk:high because this workflow is what publishes production images, the demo site, and apidoc.

  

_{Sent by Cursor Automation: Automatic PR review}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.15%. Comparing base (9e38a9a) to head (014039b).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2761   +/-   ##
=======================================
  Coverage   99.15%   99.15%           
=======================================
  Files        1190     1190           
  Lines       25057    25057           
=======================================
  Hits        24846    24846           
  Misses        211      211           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cloudflare-workers-and-pages]

Deploying gladys-plus with    Cloudflare Pages

Latest commit:	014039b
Status:	✅  Deploy successful!
Preview URL:	https://a0b2721e.gladys-plus.pages.dev
Branch Preview URL:	https://claude-github-action-release.gladys-plus.pages.dev

View logs

[cursor]

Follow-up commit 014039b addresses the blocking recovery issue from the previous review.

What looks good now

• Split prepare (human-opened PR so required checks run) → tag-on-master is the right shape for branch protection without a bypass token.
• Tag creation and dispatch are separated: if the tag already points at GITHUB_SHA, the job still re-dispatches, so a failed gh workflow run loop is recoverable via Actions re-run.
• Retry around each dispatch covers the common “tag not visible to the API yet” race.
• prepare-release fails clearly when release/vX.Y.Z already exists on the remote.
• The workflow header documents that editing root package.json version on master ships a release.

Residual (non-blocking)

• A re-run always re-dispatches all three downstream workflows (including ones that already started). That is the right tradeoff for recovery; operators can also workflow_dispatch those workflows on the tag directly if needed.
• There is still no workflow_dispatch on create-release-tag itself — recovery is “re-run this job” or manual downstream dispatch. Fine given the error text and the downstream triggers.

Keeping risk:high because this path publishes production images, demo, and apidoc. No needs:human-review — this is mechanical CI/protection plumbing, not product philosophy.

CI is green. Approving.

  

_{Sent by Cursor Automation: Automatic PR review}