feat: add production deploy and automatic staging sync - #75
Conversation
- make deploy-prod rebases `production` onto `main` and force-pushes (with lease) after a confirmation prompt, for manually triggering a production deploy. - .github/workflows/sync-staging.yml keeps `staging` in sync with `main` automatically on every merge via scripts/sync-staging.sh. - Document both flows in RUNBOOK.md and README.md.
github-actions
Bot
added
the
area: infra
|
Warning Review limit reached
Next review available in: 24 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughAdds GitHub Actions automation to synchronize ChangesDeployment automation
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Main
participant SyncWorkflow
participant SyncScript
participant Staging
Main->>SyncWorkflow: push or manual dispatch
SyncWorkflow->>SyncScript: execute sync-staging.sh
SyncScript->>Staging: rebase onto main
SyncScript->>Staging: force-with-lease push
sequenceDiagram
participant Developer
participant Make
participant DeployScript
participant Production
Developer->>Make: run deploy-prod
Make->>DeployScript: invoke shell or PowerShell script
DeployScript->>Production: rebase onto main
DeployScript->>Developer: request confirmation
DeployScript->>Production: force-with-lease push
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/sync-staging.yml:
- Around line 27-28: Update the git identity configuration in the workflow to
use the standard GitHub Actions bot name and email instead of the hardcoded
personal identity, preserving the existing configuration steps.
In `@scripts/deploy-prod.sh`:
- Around line 64-70: Update the read command in the confirmation block of the
deployment script to tolerate EOF by appending the requested non-failing
fallback, allowing execution to continue to the existing case statement and
print its clean abort message in non-interactive environments.
In `@scripts/sync-staging.sh`:
- Around line 16-26: Update the deployment-branch initialization logic in
scripts/sync-staging.sh lines 16-26, scripts/deploy-prod.sh lines 32-42, and
scripts/deploy-prod.ps1 lines 25-40 to fetch the entire remote rather than named
branches, detect whether the remote sync branch exists, and create or reset the
local branch from that remote branch when present; otherwise, fall back to
branching from main. Use shell syntax in the two .sh scripts and PowerShell
syntax in deploy-prod.ps1, preserving strict-error behavior and avoiding
captured standard output during the PowerShell existence check.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 42284443-9c1a-4e9e-9576-faaa0d26b040
📒 Files selected for processing (7)
.github/workflows/sync-staging.ymlMakefileREADME.mdRUNBOOK.mdscripts/deploy-prod.ps1scripts/deploy-prod.shscripts/sync-staging.sh
…g sync - Resolve sync-staging.yml's git identity from github.actor instead of a hardcoded personal name/email, so forks of this template don't silently force-push commits attributed to someone else. - Switch to a PAT (SYNC_STAGING_PAT) for the staging sync push, since pushes made with the default GITHUB_TOKEN don't trigger other on:push workflows and would leave CD silently un-triggered. - Harden deploy-prod.sh/.ps1 and sync-staging.sh: fetch the whole remote and fall back to branching from main instead of crashing when the staging/production branch doesn't exist yet (first run of the template). - Make deploy-prod.sh's confirmation prompt tolerate EOF in non-interactive environments instead of crashing past the abort message. - Update RUNBOOK.md with the PAT setup steps and rationale.
1 participant
Summary
make deploy-prodrebasesproductionontomainand force-pushes (with lease) after a confirmation prompt — the manual trigger for a production deploy..github/workflows/sync-staging.ymlkeepsstagingin sync withmainautomatically on every merge, viascripts/sync-staging.sh(same rebase + force-with-lease model, but unattended).RUNBOOK.md("Triggering a deploy" section, split into Staging (automatic) / Production (manual)) andREADME.md.Test plan
Settings → Actions → General → Workflow permissionsis set to "Read and write permissions" so the sync-staging workflow can push.stagingis a protected branch, add a bypass rule for the workflow's push identity.Sync Stagingworkflow runs and fast-forwardsstagingto matchmain.make deploy-prodagainst a test repo state to confirm the confirmation prompt and push behave as documented.Summary by CodeRabbit
New Features
Documentation