Deployment failing due to seed not working
zabirauf opened this issue ยท 13 comments
Have you experienced this bug with the latest version of the template?
Yes
Steps to Reproduce
Running the CI/CD pipeline through github actions or the fly deploy
and then I get error that results in failure of deployment.
Expected Behavior
Deployment works and seeding succeeds
Actual Behavior
2022-12-29T09:58:59Z app[63b7991f] sea [info]Running seed command `ts-node --require tsconfig-paths/register prisma/seed.ts` ...
2022-12-29T09:58:59Z app[63b7991f] sea [info]An error occurred while running the seed command:
2022-12-29T09:58:59Z app[63b7991f] sea [info]Error: Command failed with ENOENT: ts-node --require tsconfig-paths/register prisma/seed.ts
2022-12-29T09:58:59Z app[63b7991f] sea [info]spawn ts-node ENOENT
Looks like as the "prisma.seed" in the package.json and using ts-node while the Dockerfile in production image doesn't have ts-node so it just fails. I couldn't find where the prisma seed is being invoked from either in docker file or elsewhere so not sure what needs to be moved where.
prisma db seed
will automagically run when prisma does migrations https://www.prisma.io/docs/guides/database/seed-database#integrated-seeding-with-prisma-migrate
@mcansh the main issue I see is the following.
Error: Command failed with ENOENT: ts-node --require tsconfig-paths/register prisma/seed.ts
I think that seems to happen because the Dockerfile only copies the node_modules that are in production dependency while the ts-node
is in devDependencies
. I tried changing that in docker file and that fixed the issue.
FROM base
WORKDIR /myapp
COPY --from=production-deps /myapp/node_modules /myapp/node_modules
This issue has been automatically marked stale because we haven't received a response from the original author in a while ๐. This automation helps keep the issue tracker clean from issues that are not actionable. Please reach out if you have more information for us or you think this issue shouldn't be closed! ๐ If you don't do so within 7 days, this issue will be automatically closed.
I can confirm that Fly is not automatically seeding the DB when deploying with this stack. I've reached out to Fly support to see what can be changed. I believe the Indie Stack had a similar issue and a change was made that got it working.
@rubys and I are already collaborating on smoothing out the deploy path with Remix in superfly/flyctl#2092, which should fix all these problems normally
From my testing so far, removing --require tsconfig-paths/register
allows the seeding to proceed for at least the example provided by this stack. If, for some reason, tsconfig-paths
is really required for seeding, it should no longer be a devDependency. Either way, it is likely that some change to this stack is required in addition to the changes I'm making to fly.
@kentcdodds Can you remember why --require tsconfig-paths/register
was added to the seed script in the first place?
It's so you can import things using the ~
feature common to most Remix app setups.
@kentcdodds So I guess we should move tsconfig-paths
to dependencies
then?
Although I don't think seeding is happening in production, so it's fine to have it in devDependencies
๐ค
For now I am getting around it this way:
- create a
tsconfig.seed.json
for compiling theprisma/seed.ts
to JS
"include": ["./prisma/seed.ts"],
"compilerOptions": {
"lib": ["ES2019"],
"target": "ES2019",
"moduleResolution": "node",
"module": "CommonJS",
"esModuleInterop": true,
"resolveJsonModule": false,
"skipLibCheck": true,
"experimentalDecorators": true,
"outDir": "./seed-dist",
"baseUrl": ".",
"paths": {
"~/*": ["./app/*"]
}
}
}
-
Add this script to my
package.json
:
"seed:build": "tsc --project ./tsconfig.seed.json && tsc-alias -p ./tsconfig.seed.json"
-
Run the script to generated a compiled JS seed file at the
seed-dist/seed.js
path. -
Commit and deploy.
-
After deploy
fly ssh
to the app, and runnode myapp/seed-dist/seed.js
.
This could probably be automated, but I still consider it a workaround and not a long term solution. The reason this compilation is necessary is because trying to fly ssh
and run ts-node prisma/seed.ts
leads to OOM and other dependency errors. Hope this is helpful for anyone until the stack is updated to automate it.
Although I don't think seeding is happening in production, so it's fine to have it in devDependencies ๐ค
With fly.io, seeding is run using the same image as what will be used in production.
@rubys Should we create another build for doing so?
All tsconfig-paths
docs are referring to installing it as a dev dependency
On fly.io, build machines don't have access to secrets or postgres databases. Looking at the prisma documentation, it looks like seeds aren't applied on the first prisma migrate deploy
, and I don't see any information on the bluestack readme on how to apply seeds in production - am I just missing it?
In any case, the way it works out is that the only place where you can run your seed script on fly.io machines is on a machine that is set up for production.