fix: clean up deployment artifacts and update deployment docs#12
fix: clean up deployment artifacts and update deployment docs#12support371 merged 4 commits intomainfrom
Conversation
These root-level directories contained Next.js-specific code (process.env.NEXT_PUBLIC_*, next/headers imports, Next.js middleware patterns) that are not used by this Vite SPA. The actual app uses src/components/ and src/lib/ via the @ alias. Co-Authored-By: GEM CYBERSECURITY-MONITORING ASSIST <Analyzer@gemcybersecurityassist.com>
The .env file was committed before the .gitignore rule was in place. It is already listed in .gitignore but was still tracked. This removes it from version control while keeping the local file. Environment variables should be configured in Vercel project settings, not committed to the repository. Co-Authored-By: GEM CYBERSECURITY-MONITORING ASSIST <Analyzer@gemcybersecurityassist.com>
The previous DEPLOYMENT.md was a leftover from an earlier Next.js-based setup and contained incorrect references: - Wrong project name (Gem-Assist vs gem-enterprise) - Non-existent TOOLHOUSE_API_KEY env var - Non-existent /api/health and /api/gem-assist endpoints - NEXT_PUBLIC_ prefix warnings (irrelevant for Vite) - GitHub OAuth references (app uses email/password via Supabase) - Stale post-deploy checklist routes Updated to reflect the actual Vite + React SPA with correct: - Environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY) - Vercel dashboard and local setup instructions - SPA routing documentation - Post-deploy verification checklist matching real app routes - Security guidance appropriate for Vite client-side builds Co-Authored-By: GEM CYBERSECURITY-MONITORING ASSIST <Analyzer@gemcybersecurityassist.com>
Original prompt from GEM
|
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| ### Portal (authenticated) | ||
| - [ ] `/portal/dashboard` loads after login. | ||
| - [ ] `/portal/services`, `/portal/community`, `/portal/workspace` are accessible. | ||
| - [ ] `/profile`, `/support` pages load correctly. |
There was a problem hiding this comment.
🟡 DEPLOYMENT.md post-deploy checklist omits /settings route required by CLAUDE.md
CLAUDE.md explicitly lists /settings as part of the portal scope ("Portal scope to keep") and its testing checklist requires verifying "profile/settings/support routes load correctly". The updated DEPLOYMENT.md Post-Deploy Verification Checklist at line 95 only checks /profile and /support but omits /settings (which exists in the app at src/App.tsx:213 as a redirect to /portal/settings). This means the required route verification will be skipped during post-deploy checks.
| - [ ] `/profile`, `/support` pages load correctly. | |
| - [ ] `/profile`, `/settings`, `/support` pages load correctly. |
Was this helpful? React with 👍 or 👎 to provide feedback.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0775ebb20f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ## Overview | ||
|
|
||
| This guide provides instructions for deploying and managing the Gem-Assist project on Vercel. | ||
| This guide provides instructions for deploying and managing the GEM Enterprise authenticated portal on Vercel. This is a **Vite + React SPA** (Single Page Application) — there are no serverless functions or API routes. |
There was a problem hiding this comment.
The new overview states there are "no serverless functions or API routes," but the frontend still depends on Supabase Edge Functions (src/pages/Contact.tsx calls supabase.functions.invoke("contact-form") and src/components/GemAssist.tsx calls /functions/v1/gem-assist). With this wording, operators following this guide can skip provisioning/checking function runtime secrets (for example LOVABLE_API_KEY in supabase/functions/gem-assist/index.ts), which leads to contact/chat features failing after an otherwise successful Vercel deploy.
Useful? React with 👍 / 👎.
support371
left a comment
support371
left a comment
There was a problem hiding this comment.
Thanks for the cleanup here — removing the stale Next.js-era root lib/ / components/ artifacts and untracking .env both look directionally right.
I do see one blocking documentation inconsistency before merge: DEPLOYMENT.md now says the required Vercel vars are VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY, and it also says .env.example documents the required variables. But .env.example still includes VITE_SUPABASE_PROJECT_ID.
Please either remove VITE_SUPABASE_PROJECT_ID from .env.example if it is no longer used, or update the deployment docs to explain why it is still needed. Right now the docs and example env file are out of sync, which creates setup ambiguity.
|
Thanks for the cleanup work here — the removal of the stale root-level Next.js artifacts and the .env untracking both make sense. I re-checked the final PR state, and there are still blocking documentation gaps before merge: Please align the docs and env example with the actual runtime dependencies, then this should be in much better shape. |
…SUPABASE_PROJECT_ID, add /settings to checklist - Corrected Overview: the app relies on Supabase Edge Functions (contact-form, gem-assist), not 'no serverless functions' - Added 'Supabase Edge Functions' section documenting both functions, their triggers, and required secrets (LOVABLE_API_KEY, auto-injected Supabase vars) - Added VITE_SUPABASE_PROJECT_ID to env var table and Vercel setup steps to match .env.example - Split env var docs into Client-side and Server-side subsections - Added /settings to Portal post-deploy checklist - Added Backend (Supabase Edge Functions) verification section to checklist Co-Authored-By: GEM CYBERSECURITY-MONITORING ASSIST <Analyzer@gemcybersecurityassist.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
1 participant
Summary
Cleans up deployment-related issues left over from a previous Next.js-based setup that no longer applies to this Vite SPA.
Three changes:
Remove stale root-level
lib/andcomponents/directories — These contained Next.js server-side code (next/headers,next/server,process.env.NEXT_PUBLIC_*) that is completely unused by the Vite app. The actual app imports fromsrc/lib/andsrc/components/via the@alias. Verified with grep that nothing undersrc/imports from these root paths.Remove
.envfrom git tracking — The.envfile (containing Supabase anon key and URL) was committed before.gitignorewas set up. Removed from tracking withgit rm --cached; the local file is preserved. Environment variables should be configured in Vercel project settings, not checked into the repo.Rewrite
DEPLOYMENT.md— The previous version referenced the wrong project name ("Gem-Assist"), a non-existentTOOLHOUSE_API_KEY, non-existent API routes (/api/health,/api/gem-assist), Next.js conventions, and GitHub OAuth. Updated to accurately document the Vite + React SPA with correct env vars, setup steps, SPA routing notes, and a verification checklist matching the real app routes.Updates since last revision
Addressed review feedback on
DEPLOYMENT.md:contact-formandgem-assist). Added a dedicated "Supabase Edge Functions" section documenting each function's trigger, purpose, and required secrets..env.example— AddedVITE_SUPABASE_PROJECT_IDto the env var table and Vercel setup steps (it was in.env.examplebut missing from the docs). Split env var documentation into Client-side and Server-side subsections, with the server-side section covering Supabase Dashboard secrets (SUPABASE_URL,SUPABASE_SERVICE_ROLE_KEY,LOVABLE_API_KEY)./settingsto post-deploy checklist — Was missing from the Portal (authenticated) verification section.contact-formandgem-assistEdge Functions work post-deploy.Review & Testing Checklist for Human
contact-formsaves tocontact_submissionstable andgem-assistusesLOVABLE_API_KEYto callai.gateway.lovable.dev. These were inferred from readingsupabase/functions/*/index.tsbut not tested end-to-end.VITE_SUPABASE_PROJECT_IDis actually required — It's in.env.exampleandsupabase/config.toml, but verify it's used at runtime by the frontend. If not needed, it should be removed from.env.exampleinstead..envbeing in the repo — Confirm env vars are set in Vercel project settings, not read from the committed file.lib/orcomponents/— Grep found no imports fromsrc/into these paths, but verify no external tooling (e.g., Vercel build plugin, shadcn CLI config) depends on them. Note:components.jsonaliases point to@/componentsand@/libwhich resolve tosrc/via Vite, not the deleted root dirs.Recommended test plan: Run a fresh clone →
npm install && npm run build→ deploy to a preview environment → walk through the post-deploy verification checklist in DEPLOYMENT.md, paying special attention to the contact form submission and GEM AI Assistant chat widget (Edge Function calls).Notes
lib/supabase/server.tsandlib/supabase/proxy.tsimported fromnext/headersandnext/server— these would have caused build failures if ever accidentally imported into the Vite app.LOVABLE_API_KEYis a server-side secret managed in the Supabase Dashboard, not in Vercel or the repo. It is only referenced insupabase/functions/gem-assist/index.tsviaDeno.env.get().Link to Devin session: https://app.devin.ai/sessions/ab7713f2cda24e52b2ec959cd95758d7
Requested by: @support371