ci: add manual Tag Staging Release workflow

[FSM1]

Summary

• Adds a workflow_dispatch action ("Tag Staging Release") that creates staging tags from existing release tags (e.g. v0.3.0 → v0.3.0-staging-rc-1)
• Auto-increments RC number based on existing staging tags
• Uses staging-approval environment for reviewer gate, removing the need for double-approval prompts on the deploy workflow

Changes

• New: .github/workflows/tag-staging.yml — manual trigger, validates tag exists, calculates next RC, creates and pushes staging tag
• GitHub Settings: staging-approval environment created with required reviewers; staging environment reviewers removed (secrets/vars unchanged)

Test plan

• Trigger "Tag Staging Release" from Actions tab with v0.3.0 — verify approval prompt appears
• After approval, verify v0.3.0-staging-rc-2 tag is created and deploy-staging triggers without additional prompts
• Verify invalid tag input (e.g. v99.99.99) fails with clear error

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Added a new workflow to automate staging release tagging with a manual trigger; it validates tags, computes the next staging RC number, creates and pushes a staging RC tag, and emits a notice to kick off the staging deploy.

[coderabbitai]

Walkthrough

Adds a new manual GitHub Actions workflow that validates a provided release tag, computes the next staging RC number, creates and pushes a staging tag (e.g., v1.2.3-staging-rc-1), and emits a notice to trigger the deploy-staging workflow. (49 words)

Changes

Cohort / File(s)	Summary
GitHub Actions workflow .github/workflows/tag-staging.yml	New workflow "Tag Staging Release": accepts release_tag input, verifies tag exists, calculates next -staging-rc-N suffix from existing tags, creates & pushes the new staging tag, sets outputs and a step summary, and emits a notice to trigger deploy-staging.

Sequence Diagram(s)

sequenceDiagram
    participant User as User
    participant GHWF as Tagging Workflow
    participant Git as Git Remote
    participant Deploy as deploy-staging Workflow

    User->>GHWF: workflow_dispatch(release_tag)
    GHWF->>Git: verify tag exists
    GHWF->>Git: list tags -> compute next RC N
    GHWF->>Git: create & push `<tag>-staging-rc-N`
    GHWF->>GHWF: set outputs & step summary
    GHWF->>Deploy: emit notice / trigger deploy-staging
    Deploy->>Git: (deploys using new staging tag)

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• docs: document staging-rc tag naming convention #72: Adds/docs the v-staging-rc- tagging convention implemented by this workflow.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'ci: add manual Tag Staging Release workflow' directly and clearly describes the main change - adding a new GitHub Actions workflow for manual tag staging releases.
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.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/tag-staging-workflow

---

No actionable comments were generated in the recent review. 🎉

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @.github/workflows/tag-staging.yml:
- Around line 23-50: The run blocks currently interpolate ${{ inputs.release_tag
}} directly into shell code, enabling script injection; instead export the input
into a safe environment variable at the step level (e.g., env: RELEASE_TAG: ${{
inputs.release_tag }}) and reference it inside the scripts as "$RELEASE_TAG"
(properly quoted) in the "Validate release tag exists", "Calculate next RC
number" (id: rc, where you build STAGING_TAG and write to
GITHUB_OUTPUT/GITHUB_STEP_SUMMARY), and "Create and push staging tag" steps;
likewise set an env var for the produced staging tag (e.g., STAGING_TAG) before
using it in the git tag/git push commands to ensure the shell treats values as
data not code.

🧹 Nitpick comments (2)

.github/workflows/tag-staging.yml (2)

33-35: Minor: dots in sed pattern are treated as regex wildcards.

In sed "s/${TAG}-staging-rc-//", the dots in TAG (e.g., v0.3.0) match any character. Unlikely to cause a real problem given typical tag naming, but you can escape them for correctness using sed "s/$(echo "$TAG" | sed 's/[.]/\\./g')-staging-rc-//" or simply use shell parameter expansion instead:

-          LAST_RC=$(git tag -l "${TAG}-staging-rc-*" | sed "s/${TAG}-staging-rc-//" | sort -n | tail -1)
+          LAST_RC=$(git tag -l "${TAG}-staging-rc-*" | while read -r t; do echo "${t#"${TAG}-staging-rc-"}"; done | sort -n | tail -1)

---

5-9: Consider adding input format validation.

The tag existence check on line 25 is the primary guard, but adding a regex validation (e.g., ^v[0-9]+\.[0-9]+\.[0-9]+$) early in the workflow would reject obviously malformed inputs before any git operations, providing defense-in-depth — especially relevant if the script injection fix hasn't been applied yet.