Run deployment verification on pull requests#8
Conversation
Review Summary by QodoRun deployment verification on pull requests
WalkthroughsDescription• Run deployment verification on pull requests • Move concurrency settings to deploy job only • Prevent deployment on pull request events • Verification runs on both PR and push events Diagramflowchart LR
A["Workflow Trigger"] -->|pull_request| B["Verify Job"]
A -->|push| B
A -->|workflow_dispatch| B
B -->|Success| C["Deploy Job"]
C -->|Conditional| D["Deploy on push/dispatch only"]
E["Concurrency Control"] -->|Moved to| C
File Changes1. .github/workflows/deploy-lightsail.yml
|
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe deploy workflow now accepts pull_request events to trigger verification steps, but gates actual deployment to run only on push or manual workflow_dispatch events. This allows pull request checks without automating deployments from PRs. ChangesWorkflow Trigger and Deployment Gating
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
Code Review by Qodo
1. Deploys unverified main HEAD
|
| if: github.event_name == 'push' || github.event_name == 'workflow_dispatch' | ||
| environment: production | ||
| concurrency: | ||
| group: lightsail-production | ||
| cancel-in-progress: false |
There was a problem hiding this comment.
1. Deploys unverified main head 🐞 Bug ≡ Correctness
The deploy SSH script resets the server to origin/main rather than deploying the workflow’s triggering commit SHA, so queued/overlapping runs can deploy a different (later) commit than the one verified. This breaks the verify→deploy guarantee and can ship untested code to production.
Agent Prompt
### Issue description
The deploy step deploys `origin/main` (current HEAD) instead of the commit that the workflow verified, so production can receive code that was never linted/tested/built by that run.
### Issue Context
The `deploy` job is serialized via `concurrency`, which means it can run after additional commits land on `main`. The remote script currently does `git reset --hard origin/main`, which deploys the latest main at execution time.
### Fix Focus Areas
- .github/workflows/deploy-lightsail.yml[48-76]
### Suggested fix
- Pass the triggering SHA into the deploy script (e.g., env `COMMIT_SHA: ${{ github.sha }}`), and on the server:
- `git fetch origin $COMMIT_SHA`
- `git reset --hard $COMMIT_SHA`
- Optionally, also consider `cancel-in-progress: true` for the deploy concurrency group if the desired behavior is to only deploy the latest push.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Summary by CodeRabbit
Chores