Fix install.sh --seed to run migrations before seeding#84
Conversation
The --seed flag skipped migrations entirely (migrations only ran when SEED was false), so 'install.sh --seed <skill>' tried to seed into tables that were never created and failed immediately. Migrations now always run, with seeds applied afterwards when --seed is passed, matching the script's documented behaviour.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df53da0e87
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| done | ||
| fi | ||
| # Always run migrations. With --seed, seeds run afterwards (see below). | ||
| for skill in $INSTALL_ORDER; do |
There was a problem hiding this comment.
Preserve seed-only runs on installed schemas
When --seed is used against a schema that was already installed (for example the documented skills/docs/build-a-skill.md flow installs the skill, then runs ./scripts/install.sh --seed notes), this unconditional migration loop now reruns the skill and dependency migrations before seeding. The migrations are not idempotent (identity/migration.sql uses plain CREATE TYPE/CREATE TABLE), so psql aborts on duplicate objects and the seed phase is never reached; the previous guard allowed this seed-after-install workflow to work.
Useful? React with 👍 / 👎.
install.sh --seed now runs migrations before seeding, so the install-test job can no longer reuse the already-migrated skene_test database for the seed step (re-running migrations errors on duplicate types/tables). Run the install+seed step against a fresh skene_seed_test database instead.
Reusable end-to-end check: applies all skills via install.sh --seed, adds a second tenant, and confirms RLS isolates tenants under the authenticated role with auth.uid() resolved from the JWT sub claim. Intended for a local Supabase / dev database.
What
skills/scripts/install.sh --seedskipped migrations entirely and jumped straight to seeding, so it tried to insert into tables that were never created.The migration loop was guarded by
if [[ "$SEED" != true ]], making migrations and seeding mutually exclusive. Running the documentedinstall.sh --seed all(or--seed <skill>) failed immediately:This contradicts the script's own usage text (
--seed <skill>= "Install and seed a skill").Fix
Migrations now always run, with seeds applied afterwards when
--seedis passed.Verification
Tested against a fresh Postgres 16 (with the stock Supabase
auth.uid()stub) before and after the fix:--seed allfailed on the first seed file (no tables existed).--seed allruns 19 migrations + 19 seeds, exit 0, zero errors.updated_attriggers, seed data present.commerce→ identity→crm→billing→commerce) also verified clean.The skill SQL itself was already sound — this was purely a wrapper-script bug.
https://claude.ai/code/session_01LjP49hPKSUJVkRuqYzRbG6
Generated by Claude Code