Skip to content

Run deployment verification on pull requests#8

Merged
BeforeLights merged 1 commit into
mainfrom
dev
May 7, 2026
Merged

Run deployment verification on pull requests#8
BeforeLights merged 1 commit into
mainfrom
dev

Conversation

@BeforeLights
Copy link
Copy Markdown
Contributor

@BeforeLights BeforeLights commented May 7, 2026

Summary by CodeRabbit

Chores

  • Updated CI/CD workflow configuration to enhance pull request verification and refine deployment process controls.

@qodo-code-review
Copy link
Copy Markdown

Review Summary by Qodo

Run deployment verification on pull requests

✨ Enhancement

Grey Divider

Walkthroughs

Description
• 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
Diagram
flowchart 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
Loading

Grey Divider

File Changes

1. .github/workflows/deploy-lightsail.yml ⚙️ Configuration changes +7/-4

Add PR verification and conditional deployment logic

• Added pull_request trigger for main branch to run verification on PRs
• Removed concurrency settings from workflow level
• Added conditional check to deploy job to prevent deployment on pull requests
• Moved concurrency settings to deploy job with same configuration

.github/workflows/deploy-lightsail.yml


Grey Divider

Qodo Logo

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 7, 2026

Review Change Stack
No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9374a7b8-2a35-45c6-a7ad-a93433bc1217

📥 Commits

Reviewing files that changed from the base of the PR and between 4596c7a and dccb298.

📒 Files selected for processing (1)
  • .github/workflows/deploy-lightsail.yml

📝 Walkthrough

Walkthrough

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

Changes

Workflow Trigger and Deployment Gating

Layer / File(s) Summary
Workflow Triggers
.github/workflows/deploy-lightsail.yml
pull_request event targeting main is added to workflow triggers alongside existing push and workflow_dispatch.
Deploy Job Conditional
.github/workflows/deploy-lightsail.yml
deploy job gains an if condition restricting execution to push or workflow_dispatch events; environment and concurrency configuration is reorganized under the conditional block.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

Poem

🐰 A workflow so swift, now pulls requests flow,

Verification runs free, but deployments say "no"—

Only push and dispatch may touch Lightsail's shore,

PRs inspect safely, yet never deploy more! ✨

🚥 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 accurately reflects the main change: enabling deployment verification to run on pull requests in addition to push and manual triggers.
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.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch dev

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.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


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

@qodo-code-review
Copy link
Copy Markdown

qodo-code-review Bot commented May 7, 2026

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

Grey Divider


Action required

1. Deploys unverified main HEAD 🐞 Bug ≡ Correctness
Description
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.
Code

.github/workflows/deploy-lightsail.yml[R52-56]

+    if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
    environment: production
+    concurrency:
+      group: lightsail-production
+      cancel-in-progress: false
Evidence
The workflow verifies code in the verify job, but the deploy job is serialized and can run
later; when it does, the remote script deploys whatever origin/main points to at that moment, not
the commit that triggered this workflow run.

.github/workflows/deploy-lightsail.yml[13-47]
.github/workflows/deploy-lightsail.yml[48-56]
.github/workflows/deploy-lightsail.yml[70-76]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### 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



Remediation recommended

2. PR runs not canceled 🐞 Bug ➹ Performance
Description
Adding the pull_request trigger without workflow/job concurrency cancellation means each new PR
push can start another full verify run instead of canceling obsolete runs. This wastes CI
resources and can slow feedback/other workflows due to runner contention.
Code

.github/workflows/deploy-lightsail.yml[R4-6]

+  pull_request:
+    branches:
+      - main
Evidence
The workflow now runs on pull_request, but there is no workflow-level (or verify job-level)
concurrency configured; the only concurrency block is scoped to the deploy job, so redundant
verify runs will accumulate on repeated PR updates.

.github/workflows/deploy-lightsail.yml[3-16]
.github/workflows/deploy-lightsail.yml[48-56]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Repeated pushes to the same PR will run multiple `verify` jobs concurrently because the workflow has no concurrency cancellation for PR verification.

### Issue Context
This workflow is now triggered by `pull_request`, and `verify` is the first job that runs. Only `deploy` has a concurrency group, so `verify` runs are not deduped.

### Fix Focus Areas
- .github/workflows/deploy-lightsail.yml[1-16]
- .github/workflows/deploy-lightsail.yml[13-47]

### Suggested fix
Add concurrency that cancels in-progress runs for the same PR/ref, for example at the workflow level:
```yml
concurrency:
 group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
 cancel-in-progress: ${{ github.event_name == 'pull_request' }}
```
(or apply a similar `concurrency` block to the `verify` job).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

Comment on lines +52 to +56
if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
environment: production
concurrency:
group: lightsail-production
cancel-in-progress: false
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

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

@BeforeLights BeforeLights merged commit ea95ab3 into main May 7, 2026
3 checks passed
@coderabbitai coderabbitai Bot mentioned this pull request May 7, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant