Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment failing due to seed not working #143

Open
zabirauf opened this issue Dec 29, 2022 · 13 comments
Open

Deployment failing due to seed not working #143

zabirauf opened this issue Dec 29, 2022 · 13 comments

Comments

@zabirauf
Copy link

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.

@mcansh
Copy link
Contributor

mcansh commented Dec 31, 2022

prisma db seed will automagically run when prisma does migrations https://www.prisma.io/docs/guides/database/seed-database#integrated-seeding-with-prisma-migrate

@zabirauf
Copy link
Author

zabirauf commented Dec 31, 2022

@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

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot added the needs-response We need a response from the original author about the issue label Apr 17, 2023
@graysonhicks
Copy link

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.

@MichaelDeBoey
Copy link
Member

@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

@github-actions github-actions bot removed the needs-response We need a response from the original author about the issue label Apr 19, 2023
@rubys
Copy link

rubys commented Apr 19, 2023

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.

@MichaelDeBoey
Copy link
Member

@kentcdodds Can you remember why --require tsconfig-paths/register was added to the seed script in the first place?

@kentcdodds
Copy link
Member

It's so you can import things using the ~ feature common to most Remix app setups.

@MichaelDeBoey
Copy link
Member

MichaelDeBoey commented Apr 19, 2023

@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 🤔

@graysonhicks
Copy link

graysonhicks commented Apr 20, 2023

For now I am getting around it this way:

  1. create a tsconfig.seed.json for compiling the prisma/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/*"]
      }
    }
  }
  1. Add this script to my package.json:
    "seed:build": "tsc --project ./tsconfig.seed.json && tsc-alias -p ./tsconfig.seed.json"

  2. Run the script to generated a compiled JS seed file at the seed-dist/seed.js path.

  3. Commit and deploy.

  4. After deploy fly ssh to the app, and run node 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.

@rubys
Copy link

rubys commented May 2, 2023

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.

@MichaelDeBoey
Copy link
Member

@rubys Should we create another build for doing so?
All tsconfig-paths docs are referring to installing it as a dev dependency

@rubys
Copy link

rubys commented May 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants