### TL;DR
Improved the production deployment workflow with better error handling and clearer instructions.
### What changed?
- Renamed `auto-merge-prod.yml` to `deploy-to-prod-command.yml` to better reflect its purpose
- Updated workflow name from "Deploy Production" to "Deploy to Production Command"
- Changed job name to "Merge Staging to Production" for clarity
- Added proper error handling when rebase fails by posting a comment to the PR instead of failing silently
- Added explicit condition for the push step to only run when rebase succeeds
- Updated the sync-production workflow to include clear instructions in the PR body instead of creating a draft PR
- Added guidance in the PR body explaining how to deploy using the `/deploy` command
### How to test?
1. Create a PR from staging to main
2. Comment `/deploy` on the PR to trigger the deployment workflow
3. Verify that the workflow correctly merges staging into main when possible
4. Test the error case by creating a conflict between staging and main, then verify the workflow posts a helpful error comment
### Why make this change?
This change improves the developer experience by providing clearer feedback during the deployment process. The improved error handling helps developers understand when manual intervention is needed, and the updated PR template provides explicit instructions on how to complete the deployment. Renaming the workflow files and jobs also makes their purpose more obvious to team members.
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit
- **Chores**
- Updated deployment workflow to require a specific comment format and label for production deploys.
- Enhanced error handling during rebase with clearer instructions for manual intervention.
- Automated pull requests for syncing staging to production now include deployment instructions, a production-deploy label, and are no longer created as drafts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Added a GitHub workflow to automatically deploy to production when staging PRs are approved by MrgSub.
Created a new GitHub workflow file `.github/workflows/auto-merge-prod.yml` that:
- Triggers when a pull request is approved
- Checks if the PR is from staging to main and was approved by MrgSub
- Automatically rebases main on staging
- Pushes the changes to main if the rebase is successful
1. Create a PR from staging to main
2. Have the GitHub user MrgSub approve the PR
3. Verify that the workflow runs and successfully rebases main on staging
To streamline the deployment process to production by automating the merge from staging to main when approved by the designated reviewer. This reduces manual steps and potential human error during the deployment process.
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
- **Chores**
- Introduced a new automated workflow to deploy changes to production when specific pull requests are approved. This streamlines the release process and ensures only approved updates are merged and deployed.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Send Lingo.dev PRs to staging
---
## Type of Change
Please delete options that are not relevant.
- [ ] 🐛 Bug fix (non-breaking change which fixes an issue)
- [ ] ✨ New feature (non-breaking change which adds functionality)
- [ ] 💥 Breaking change (fix or feature with breaking changes)
- [ ] 📝 Documentation update
- [ ] 🎨 UI/UX improvement
- [ ] 🔒 Security enhancement
- [ ] ⚡ Performance improvement
## Areas Affected
Please check all that apply:
- [ ] Email Integration (Gmail, IMAP, etc.)
- [ ] User Interface/Experience
- [ ] Authentication/Authorization
- [ ] Data Storage/Management
- [ ] API Endpoints
- [ ] Documentation
- [ ] Testing Infrastructure
- [ ] Development Workflow
- [ ] Deployment/Infrastructure
## Testing Done
Describe the tests you've done:
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing performed
- [ ] Cross-browser testing (if UI changes)
- [ ] Mobile responsiveness verified (if UI changes)
## Security Considerations
For changes involving data or authentication:
- [ ] No sensitive data is exposed
- [ ] Authentication checks are in place
- [ ] Input validation is implemented
- [ ] Rate limiting is considered (if applicable)
## Checklist
- [ ] I have read the [CONTRIBUTING](../CONTRIBUTING.md) document
- [ ] My code follows the project's style guidelines
- [ ] I have performed a self-review of my code
- [ ] I have commented my code, particularly in complex areas
- [ ] I have updated the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix/feature works
- [ ] All tests pass locally
- [ ] Any dependent changes are merged and published
## Additional Notes
Add any other context about the pull request here.
## Screenshots/Recordings
Add screenshots or recordings here if applicable.
---
_By submitting this pull request, I confirm that my contribution is made under the terms of the project's license._
