chore(ci): remove staging_tag promotion path from release-production

[senamakel]

Summary

• Remove the staging_tag promotion path from release-production.yml — production releases now always build from main with a fresh version bump.
• Remove release_source choice and staging_tag string inputs.
• Simplify review-approval, prepare-build, and Resolve build outputs to a single linear flow.
• Net -167 lines of workflow YAML.

Problem

• The staging_tag promotion path in release-production.yml is obsolete now that staging no longer always creates tags (per PR chore(ci): simplify release workflows — remove pretests, add commit picker and bump-only mode #3177).
• Having two build paths (staging_tag vs main_head) added complexity without clear benefit — both staging and production can now build from HEAD or a specific commit.

Solution

• Removed the release_source choice input, staging_tag string input, and the entire Path B (staging tag resolution, version verification across 4 manifest files, production tag creation from staging commit).
• review-approval now always runs (was previously conditional on release_source == 'main_head').
• prepare-build is a single linear flow: bump → verify → refresh lockfiles → commit → push → optionally tag.
• Resolve build outputs no longer branches on release_source — reads directly from the bump/push step outputs.

Submission Checklist

• N/A: CI workflow YAML changes — no application code, no testable surface
• N/A: no application code changed, diff-cover gate does not apply to workflow files
• N/A: no feature rows affected — CI-only change
• N/A: no feature IDs affected
• N/A: no external network dependencies introduced
• N/A: does not touch release-cut surfaces (it IS the release-cut surface definition)
• N/A: no linked issue

Impact

• CI only — no runtime, platform, or app-level changes.
• Simplifies the production release workflow by removing a dead code path.
• Follows up on PR chore(ci): simplify release workflows — remove pretests, add commit picker and bump-only mode #3177 which decoupled staging from production via the create_tag input.

Related

• Closes: N/A
• Follow-up PR(s)/TODOs: N/A

---

AI Authored PR Metadata (required for Codex/Linear PRs)

Linear Issue

• Key: N/A
• URL: N/A

Commit & Branch

• Branch: chore/remove-staging-tag-promotion
• Commit SHA: d565531

Validation Run

• pnpm --filter openhuman-app format:check
• N/A: pnpm typecheck — no TS changes
• N/A: Focused tests — CI workflow YAML only
• N/A: Rust fmt/check — no Rust changes
• N/A: Tauri fmt/check — no Tauri changes

Validation Blocked

• command: N/A
• error: N/A
• impact: N/A

Behavior Changes

• Intended behavior change: production releases no longer support staging_tag promotion; always build from main
• User-visible effect: simplified workflow dispatch UI (fewer inputs)

Parity Contract

• Legacy behavior preserved: default inputs (release_type=patch, commit_sha="", create_release=true) produce the same result as the old main_head path
• Guard/fallback/dispatch parity checks: N/A

Duplicate / Superseded PR Handling

• Duplicate PR(s): N/A
• Canonical PR: this one
• Resolution: N/A

Summary by CodeRabbit

• Chores
  • Simplified production release workflow by removing conditional gates and streamlining checkout logic
  • Clarified workflow input descriptions for release operations
  • Updated staging release workflow documentation regarding tag creation

[coderabbitai]

📝 Walkthrough

Walkthrough

Production release workflow removes release-source conditionals and simplifies job dependencies, checkout logic, and output resolution. Staging workflow documentation is updated to reflect optional tag creation.

Changes

Release Workflow Conditional Simplification

Layer / File(s)	Summary
Input and concurrency documentation updates .github/workflows/release-production.yml	Updated release_type and commit_sha input descriptions for clarity, and adjusted concurrency-group comments explaining production isolation.
Review approval gate and job dependency refactoring .github/workflows/release-production.yml	Removed the prior release-source conditional restriction from review-approval job and the downstream prepare-build job conditional dependencies tied to approval result and release source.
Checkout and version-bump pipeline simplification .github/workflows/release-production.yml	Simplified checkout logic to key off COMMIT_SHA non-empty state rather than compound release-source checks, and removed step-level main_head conditionals from version-bump pipeline (version computation, sync verification, Cargo lock refresh, tag checks, and commit/push).
Build output resolution simplification .github/workflows/release-production.yml	Simplified Resolve build outputs to derive version, tag, and sha directly from bump/push results and set build_ref based on create_release, removing prior staging-promotion and fallback logic.
Staging workflow documentation update .github/workflows/release-staging.yml	Updated Phase 1 header comments in staging workflow to clarify that the immutable v<version>-staging tag is created optionally based on workflow input and used for reproducible builds.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• tinyhumansai/openhuman#3177: Directly builds on prior changes to release-production.yml checkout/conditionals and prepare-build output/tag/build_ref handling.
• tinyhumansai/openhuman#3045: This PR removes/refines the review-approval and release-source conditional gating that was introduced in PR #3045.
• tinyhumansai/openhuman#2176: Both PRs modify release-production.yml job-level conditionals; this PR simplifies approval/prepare-build gating while the prior PR adds always()-based gating for skip_e2e handling.

Suggested reviewers

• sanil-23

Poem

🐰 A workflow so tangled, now flows clean and bright,
With conditionals trimmed and dependencies right,
The build pipeline sings with less branching to bear,
Release gates simplified, handled with care! ✨

🚥 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 and specifically describes the main change: removing the staging_tag promotion path from the release-production workflow.
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.}

---

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

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release-production.yml (1)

156-157: 💤 Low value

Consider using env var to mitigate template injection risk (flagged by static analysis).

While the version comes from an internal script and the workflow has an approval gate, passing steps.bump.outputs.version directly in the shell command could theoretically allow code injection if that output ever contained shell metacharacters. Using an env var is more defensive and consistent with the pattern used in nearby steps (e.g., lines 165-174).

🛡️ Suggested hardening

       - name: Verify release version sync
+        env:
+          VERSION: ${{ steps.bump.outputs.version }}
-        run: node scripts/release/verify-version-sync.js "${{ steps.bump.outputs.version }}"
+        run: node scripts/release/verify-version-sync.js "$VERSION"

🤖 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-production.yml around lines 156 - 157, Replace the
direct interpolation of the bump output in the run command for the "Verify
release version sync" step by exposing steps.bump.outputs.version as an
environment variable (e.g., VERSION) and referencing that env var in the run
invocation that calls node scripts/release/verify-version-sync.js; update the
step metadata to include env: VERSION: ${{ steps.bump.outputs.version }} and
change the run command to use the shell variable (e.g., "$VERSION") so the
version value is passed safely via env rather than inline template expansion.

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

Nitpick comments:
In @.github/workflows/release-production.yml:
- Around line 156-157: Replace the direct interpolation of the bump output in
the run command for the "Verify release version sync" step by exposing
steps.bump.outputs.version as an environment variable (e.g., VERSION) and
referencing that env var in the run invocation that calls node
scripts/release/verify-version-sync.js; update the step metadata to include env:
VERSION: ${{ steps.bump.outputs.version }} and change the run command to use the
shell variable (e.g., "$VERSION") so the version value is passed safely via env
rather than inline template expansion.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d845c071-2dc2-4a76-831f-19a45050aea4

📥 Commits

Reviewing files that changed from the base of the PR and between 57865fd and d565531.

📒 Files selected for processing (2)

• .github/workflows/release-production.yml
• .github/workflows/release-staging.yml

[sanil-23]

@senamakel the cleanup itself reads well — collapsing the two-path (staging_tag vs main_head) branching into a single linear bump -> verify -> refresh-lockfiles -> commit -> push -> optional-tag flow is a real readability win, and the Resolve build outputs simplification is correct (the version/tag/sha now come straight from the bump/push steps with no fallback gymnastics). Net -167 lines of dead path. Nice.

Two things before I can approve:

1. CI — the coverage checks are still pending, so I'll hold the final approval until they go green.

2. Docs are now out of sync. gitbooks/developing/release-policy.md (and its release-policy.zh-CN.md translation) still document the removed inputs as the supported and default release flow. After this merges, the docs describe a workflow_dispatch form that no longer exists, so an operator following them will reach for inputs that are gone:

   • The whole "Promoting to production (default flow)" section instructs running with release_source = staging_tag (described as the default) and leaving staging_tag blank to promote the latest v*-staging. That path is entirely removed by this PR.
   • The "Hotfix from main HEAD" section references release_source = main_head — which is now just the only path, not a mode you select.
   • The note that the staging_tag path is not gated by review-approval, and the "Manual approval gate" section stating the gate is scoped to release_source == 'main_head', are both stale — review-approval now runs unconditionally for every production cut, which is actually a meaningful behavior change worth calling out in the docs rather than dropping silently.

   Worth folding the doc update into this PR so the release runbook matches the workflow: replace the staging->production promotion section with the new single main-build flow, and update the approval-gate description to reflect that it always runs now.

Once CI is green and the docs are reconciled, I'll come back and approve.