feat: optimize Vercel auto-deployment and remove deployment conflicts#110
Merged
Conversation
…ment conflicts BREAKING CHANGE: Vercel is now the ONLY deployment mechanism Changes: - Enhanced vercel.json with explicit deployment configuration * Added deploymentEnabledForPR: false (tests only on PRs) * Added deploymentBranches: [main] (production from main only) * Added deploymentInvocationHook for explicit push events * Added outputDirectory specification - Disabled conflicting GitHub workflows: * Guardian workflow (main.yml) - Was duplicating Vercel build * CodeQL on main branch - Now PR/scheduled only * CI on main push - Now PR validation only - Kept validation workflows: * CI.yml runs on PRs for code quality checks * CodeQL.yml runs on schedule and PR reviews Benefits: ✅ Single source of truth (Vercel) for production deployment ✅ Eliminates workflow conflicts and duplicate builds ✅ Auto-deploys on any push to main branch ✅ Faster CI/CD pipeline ✅ Clearer deployment responsibility separation ✅ Rollback available via Vercel dashboard Post-deployment: 1. Set environment variables in Vercel Dashboard 2. Push to main triggers automatic deployment 3. Monitor at https://vercel.com/gem-enterprise See VERCEL_AUTO_DEPLOYMENT_SETUP.md for complete documentation
Remove conflicting workflows and create deployment optimization doc. Co-authored-by: GEM CYBERSECURITY-MONITORING ASSIST <228002387+support371@users.noreply.github.com>
Contributor
|
Deployment failed with the following error: Learn More: https://vercel.com/docs/concepts/projects/project-configuration |
Reviewer's GuideConfigures Vercel as the sole production deployment mechanism by tightening vercel.json git/deployment settings, disabling main-branch GitHub Actions workflows that previously built/deployed on push, and documenting the new Vercel-centric deployment flow and environment configuration. Sequence diagram for push-to-main Vercel auto-deployment flowsequenceDiagram
actor Developer
participant GitHub
participant VercelWebhook as Vercel
participant BuildSystem as VercelBuild
participant Production as ProductionEnvironment
Developer->>GitHub: Push commit to main
GitHub-->>VercelWebhook: Push event (main branch)
VercelWebhook->>BuildSystem: Start deployment
BuildSystem->>BuildSystem: pnpm install --frozen-lockfile
BuildSystem->>BuildSystem: pnpm run db:generate
BuildSystem->>BuildSystem: pnpm run build
alt Build succeeds
BuildSystem-->>Production: Promote deployment to production
Production-->>Developer: Deployment healthy and live
else Build fails
BuildSystem-->>Production: Keep previous production version
BuildSystem-->>Developer: Report build failure in Vercel dashboard
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- Since the Guardian workflow is now effectively disabled but still invokable via
workflow_dispatch, consider either removing deployment-related steps from that workflow or deleting the file entirely to avoid accidental manual runs that conflict with the new Vercel-only deployment model. - Now that CI and CodeQL run only on pull requests, you may want to enforce a PR-only flow for
main(e.g., via branch protection rules) so that direct pushes tomaindon’t bypass the validation that this PR now relies on.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Since the Guardian workflow is now effectively disabled but still invokable via `workflow_dispatch`, consider either removing deployment-related steps from that workflow or deleting the file entirely to avoid accidental manual runs that conflict with the new Vercel-only deployment model.
- Now that CI and CodeQL run only on pull requests, you may want to enforce a PR-only flow for `main` (e.g., via branch protection rules) so that direct pushes to `main` don’t bypass the validation that this PR now relies on.
## Individual Comments
### Comment 1
<location path=".github/workflows/main.yml" line_range="1" />
<code_context>
-name: Guardian Workflow
+name: Guardian Workflow (DISABLED - Vercel Handles Deployment)
on:
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Renaming the workflow as disabled but keeping it runnable via `workflow_dispatch` may cause confusion or accidental use.
Since it remains invocable via `workflow_dispatch`, someone could still run it manually and trigger unintended side effects. If this is truly deprecated, consider removing the `workflow_dispatch` trigger, or add a top-level guard step that fails immediately with a clear message directing users to the Vercel-based deployment instead.
Suggested implementation:
```
name: Guardian Workflow (DISABLED - Vercel Handles Deployment)
on:
workflow_dispatch:
permissions:
jobs:
disabled_guard:
name: "Disabled: use Vercel-based deployment instead"
runs-on: ubuntu-latest
steps:
- name: Fail workflow because it is deprecated
run: |
echo "This workflow is deprecated. Vercel now handles deployment."
echo "Do NOT run this workflow. Use the Vercel-based deployment pipeline instead."
exit 1
```
If there are existing `jobs:` defined later in this file (e.g., build/deploy steps), they should be removed to avoid duplicate `jobs` keys and to ensure the only behavior of this workflow is the guard job that fails immediately.
</issue_to_address>
### Comment 2
<location path="VERCEL_AUTO_DEPLOYMENT_SETUP.md" line_range="229-232" />
<code_context>
+
+### Environment-Specific Logs
+- **Production:** `Vercel → Deployments → Select Production → Logs`
+- **Preview:** Each PR gets preview deployment with separate logs
+- **Build Logs:** Available for 48 hours after deployment
+
</code_context>
<issue_to_address>
**suggestion:** Preview deployment description for PRs seems inconsistent with earlier statement that PR deployments are skipped.
This conflicts with the earlier note that PR deployments are disabled (`deploymentEnabledForPR: false`, “Skips deployments for PRs”). Please update this line so it accurately matches the actual PR deployment behavior.
```suggestion
### Environment-Specific Logs
- **Production:** `Vercel → Deployments → Select Production → Logs`
- **Preview:** Disabled for PRs (`deploymentEnabledForPR: false`); no preview deployments or logs for PR branches
- **Build Logs:** Available for 48 hours after deployment
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| @@ -1,13 +1,6 @@ | |||
| name: Guardian Workflow | |||
There was a problem hiding this comment.
suggestion (bug_risk): Renaming the workflow as disabled but keeping it runnable via workflow_dispatch may cause confusion or accidental use.
Since it remains invocable via workflow_dispatch, someone could still run it manually and trigger unintended side effects. If this is truly deprecated, consider removing the workflow_dispatch trigger, or add a top-level guard step that fails immediately with a clear message directing users to the Vercel-based deployment instead.
Suggested implementation:
name: Guardian Workflow (DISABLED - Vercel Handles Deployment)
on:
workflow_dispatch:
permissions:
jobs:
disabled_guard:
name: "Disabled: use Vercel-based deployment instead"
runs-on: ubuntu-latest
steps:
- name: Fail workflow because it is deprecated
run: |
echo "This workflow is deprecated. Vercel now handles deployment."
echo "Do NOT run this workflow. Use the Vercel-based deployment pipeline instead."
exit 1
If there are existing jobs: defined later in this file (e.g., build/deploy steps), they should be removed to avoid duplicate jobs keys and to ensure the only behavior of this workflow is the guard job that fails immediately.
Comment on lines
+229
to
+232
| ### Environment-Specific Logs | ||
| - **Production:** `Vercel → Deployments → Select Production → Logs` | ||
| - **Preview:** Each PR gets preview deployment with separate logs | ||
| - **Build Logs:** Available for 48 hours after deployment |
There was a problem hiding this comment.
suggestion: Preview deployment description for PRs seems inconsistent with earlier statement that PR deployments are skipped.
This conflicts with the earlier note that PR deployments are disabled (deploymentEnabledForPR: false, “Skips deployments for PRs”). Please update this line so it accurately matches the actual PR deployment behavior.
Suggested change
| ### Environment-Specific Logs | |
| - **Production:** `Vercel → Deployments → Select Production → Logs` | |
| - **Preview:** Each PR gets preview deployment with separate logs | |
| - **Build Logs:** Available for 48 hours after deployment | |
| ### Environment-Specific Logs | |
| - **Production:** `Vercel → Deployments → Select Production → Logs` | |
| - **Preview:** Disabled for PRs (`deploymentEnabledForPR: false`); no preview deployments or logs for PR branches | |
| - **Build Logs:** Available for 48 hours after deployment |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
gem-enterprise | 1814e86 | May 10 2026, 10:12 PM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deployment Configuration Overhaul
This PR optimizes the repository for Vercel auto-deployment as the ONLY deployment mechanism.
Key Changes
1. Enhanced vercel.json Configuration
2. GitHub Actions Workflow Updates
3. Documentation
Benefits
✅ Single Source of Truth - Vercel is the only deployment system
✅ Eliminated Conflicts - No duplicate builds or conflicting workflows
✅ Faster Deployment - Simplified CI/CD pipeline
✅ Clear Responsibility - Obvious where deployment happens
✅ Easy Rollback - Via Vercel dashboard in seconds
Testing
Merge Instructions
After merge:
Rollback Plan
If issues occur:
This is a BREAKING CHANGE - Vercel now owns all production deployments.
Summary by Sourcery
Standardize on Vercel as the sole production deployment system and adjust CI workflows and documentation accordingly.
Enhancements:
Documentation: