[thomasluizon]

Closes thomasluizon/orbit-tickets#816

Change

• Replaced .github/workflows/deploy-api.yml with .github/workflows/release.yml. It runs only by manual dispatch from main, rejects a production branch other than main before checkout, checks that the checkout matches the selected branch head, and serializes releases per environment. The production Render deploy, health check, live commit check, and GitHub Deployment behavior carry forward. Staging sets its tracked branch and disables auto-deploy before triggering the selected commit, then checks staging health and records its Deployment.
• Updated infra/staging.tf to disable staging API auto-deploy, preserve its workflow-selected branch across Terraform applies, create the staging landing site with the production landing build and delivery settings, and output landing_staging_service_id.
• Updated README.md, infra/README.md, and CLAUDE.md with the manual release path and Terraform apply caution.

The workflow uses one release path for both environments so commit resolution, Render polling, health verification, and GitHub Deployment recording stay aligned. No Render service was changed by this PR branch.

Assumptions

• The staging landing site starts with tracked branch main and copies production landing headers and routes; the alternative was a staging-specific initial branch or delivery settings.
• Terraform preserves the staging landing branch after creation for its own release workflow; the alternative was resetting it to main on every apply.

Manual steps

• In the infra Terraform workspace, review a refreshed saved plan with the approved web image digests and apply it. Cancel the Render Dashboard deploy started by the staging API setting change unless that branch head is the intended release. Confirm GET https://api.render.com/v1/services/srv-dasotg8473hc739a5gjg reports autoDeploy: no, and confirm the new orbit-landing-staging site exists in the Render Staging environment.
• In thomasluizon/orbit-landing-page, open Settings > Secrets and variables > Actions > Variables and set RENDER_LANDING_STAGING_SERVICE_ID to the landing_staging_service_id Terraform output. Read the variable back in that screen and compare it with the output before the landing release workflow runs.

The RENDER_STAGING_SERVICE_ID variable is already set in thomasluizon/orbit-api to srv-dasotg8473hc739a5gjg and was read back with gh variable list. The existing RENDER_API_KEY secret is present in the repository.

Test evidence

• actionlint .github/workflows/release.yml: passed.
• terraform fmt -check -recursive infra: passed.
• terraform -chdir=infra validate: passed.
• Saved plan with -refresh=false because no Cloudflare API token is available in this worker: render_web_service.staging_api updates only auto_deploy from true to false; render_web_service.staging_web and render_web_service.production_api have no change; render_web_service.production_web is a create, not an in-place update; render_static_site.staging_landing is a create. The plan was not applied.
• dotnet build Orbit.slnx: 0 errors.
• dotnet test: 6,813 passed, 0 failed.
• Dash and timeless checks passed. No route, endpoint, or module changed, so architecture artifacts were not regenerated.

External interface evidence

• Read-only live GET https://api.render.com/v1/services/srv-dasotg8473hc739a5gjg with RENDER_MCP_TOKEN returned the projection { "id": "srv-dasotg8473hc739a5gjg", "branch": "redesign/main", "autoDeploy": "yes" }. Reproduce with curl -fsS -H "Authorization: Bearer $RENDER_MCP_TOKEN" https://api.render.com/v1/services/srv-dasotg8473hc739a5gjg | jq '{id, branch, autoDeploy}'. The Render update service reference confirms PATCH accepts branch and autoDeploy and returns both fields. No mutating Render API call was made here.
• Read-only live GET https://api.render.com/v1/services/srv-dasotg8473hc739a5gjg/deploys?limit=1 returned the projection { "deploy": { "id": "dep-dass32bl550s739k9cq0", "status": "live", "commit": { "id": "e1bbb37ad1bfb2030764da256d589f9393cec78c" } } }. Reproduce with the same authorization header and jq '.[0] | {deploy: {id: .deploy.id, status: .deploy.status, commit: {id: .deploy.commit.id}}}'. The Render trigger deploy reference, retrieve deploy reference, and list deploys reference confirm the request and response fields. The workflow sets the tracked branch before passing commitId; cross-branch POST behavior was not tested against a live service.
• gh api repos/thomasluizon/orbit-api/branches/redesign/main --jq '{name: .name, sha: .commit.sha}' returned { "name": "redesign/main", "sha": "e1bbb37ad1bfb2030764da256d589f9393cec78c" }. The GitHub branch reference confirms commit.sha.
• gh api repos/thomasluizon/orbit-api/deployments --jq '.[0] | {id: .id, ref: .ref, environment: .environment}' returned an existing deployment with id, ref, and environment; the GitHub Deployment reference confirms the create response id. A read-only status GET returned state, environment, log_url, and environment_url for that deployment.

[pullfrog]

✅ No new issues found.

Reviewed changes in commit 62bc3052 across the manual release workflow, staging Terraform resources, and deployment guidance.

• Release workflow: Selects production or staging, validates the requested branch and commit, and verifies the Render deployment before recording its GitHub Deployment.
• Staging infrastructure: Disables API auto deploy, preserves release selected branches, and provisions a landing static site with its service ID output.
• Documentation: Describes the release inputs, Terraform apply precautions, and repository variable setup.

  ^{｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud