feat: add local development seed data (Closes #405)#443
Conversation
Welcome to OSSfolio, @SakethSumanBathini! 🎉Thank you for opening this pull request and contributing to the open-source community! 🚀 To ensure a smooth review process, please make sure you have:
We will review your PR as soon as possible. Happy coding! 💻✨ |
📝 WalkthroughWalkthroughThe seed script now creates deterministic local auth users, relies on the auth trigger for profiles, and populates profile statistics, language data, score deltas, and visibility settings. Inserts are idempotent, and one profile is marked unlisted. ChangesLocal development seed
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@supabase/seed.sql`:
- Around line 25-100: Add matching auth.identities seed rows for each inserted
user in the auth.users seed block, using the corresponding user IDs and provider
identity data required by GoTrue for GitHub login. Make the identity inserts
idempotent with an appropriate conflict guard, preserving the existing
auth.users data and confirmation fields.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 90c187be-5d0b-4a39-9e6d-b4d4724076a2
📒 Files selected for processing (1)
supabase/seed.sql
… (review feedback)
PRODHOSH
added
enhancement
|
🎉 Your PR just got merged, @SakethSumanBathini — thank you for contributing to OSSfolio! Your work is now part of the project. Here's what to do next:
We really appreciate you taking the time. See you in the next PR! 🚀 |
2 participants
Summary
supabase/seed.sqlcurrently contains no SQL at all — just a comment explaining that none is needed,because profiles are created by the
handle_new_usertrigger when someone signs in.That's true, and it leaves anyone without GitHub OAuth configured — or without a Supabase project at
all — looking at an empty Explore, an empty Discover, and a
/comparewith nobody to compare. Youcan't develop against any of it.
This adds five profiles with realistic, varied data.
Related Issue
Closes #405
Type of Change
Changes Made
One file:
supabase/seed.sql.It seeds
auth.users, notpublic.profiles, and that's forced by the schema.profiles.idisreferences auth.users(id) on delete cascade, so a profile row cannot exist without an auth user —inserting straight into
public.profilesfails on the foreign key. So the seed does what a realGitHub sign-in does: it inserts an auth user with GitHub-shaped
raw_user_meta_dataand letshandle_new_userbuild the profile from it.That also keeps the file honest. If the trigger changes, the seed follows it, rather than drifting
into a second parallel definition of what a profile looks like.
Stats are then applied with an
UPDATE, because the trigger only sets identity fields (username,name, avatar_url, github_url). Score and totals normally arrive from the GitHub sync, which needs a
service-role key and network access that local dev often doesn't have — which is precisely the
situation this file exists to rescue.
The data is chosen so the features have something to exercise:
score_delta_30_daysand one negative, so the "most improved" sort added in20260710000000has something to actually sortunlisted— it renders at/lena-shipsbut must not appear on Exploreor in
/api/discover. That behaviour is easy to break and hard to notice without an examplesitting in the database
on conflict (id) do nothing, sosupabase db resetcan be re-run and this is a no-op against adatabase that already has them.
AI Usage
including which functions I changed, why I changed them, and what side effects they could create
Used Claude for coding.
Checklist
mainconsole.logleft insrc/schema.sqland a new migration file are includedDESIGN.mdand followed the design system(No schema change — this only inserts data. No UI change.)
How I tested it
I don't have a Supabase project, so I applied the schema and the actual
handle_new_usertrigger,lifted verbatim from
20260520000001_initial_schema.sql, to a local Postgres and ran the seedagainst it:
GitHub URLs all populated from
raw_user_meta_datavisibility = 'public'returns four of them in score order, and correctlyexcludes the unlisted one
What I couldn't test:
supabase db resetend-to-end against a real Supabase instance. The SQL isverified against the real trigger and a real Postgres; the CLI wiring around it I've had to take on
trust. If the
auth.userscolumn set differs from what I've assumed on your version, that'll show upimmediately on the first reset and I'll fix it.
auth.identitiesrow withsubmatching its user id, so GoTrue can authenticatethem — verified against GoTrue's real constraints (
provider_idNOT NULL, unique on(provider, provider_id))visibility = 'public'returns four in score order, correctly excluding theunlisted one
Summary by CodeRabbit