Hey everyone, for some reason. CI when I have post...
# prisma-client
j
Hey everyone, for some reason. CI when I have postgres running and run
prisma db push
I get
Copy code
{
  "timestamp": "2021-08-02T17:27:04.778303482+00:00",
  "level": "ERROR",
  "fields": {
    "is_panic": false,
    "error_code": "P1003",
    "message": "Database `<db name>.public` does not exist on the database server at `localhost:5432`."
  },
  "target": "migration_engine::logger"
}
Shouldn't it create the db if it doesn't already exist? It does on another step in CI (and locally) which is weird... the step that does not work is using docker executor and the one that does work is using ubuntu machine executor (both on circleci) Anyone have any ideas here? I am at a loss.
This is a fresh postgres instance (using
docker-compose up
) so no DBs
using prisma 2.22.1
r
@Jay Bell 👋 Is the database reachable on
localhost:5432
?
j
@Ryan Yes it is reachable otherwise the CLI wouldn't get to that part. Before I had the env variables setup correctly it would say cannot connect to.db on port 5432. I also added a wait on that port to ensure it was open before proceeding but that did not help.
r
So the same setup works locally but not in production?
Could you provide more info about your setup?
j
Locally on MacOS with postegres running in docker-compose up it works fine (creates the db if it doesn't exist then pushes the schema) On CI running inside of a docker container with a postgres docker running in parallel on the same network it works fine. On CI when running on an Ubuntu VM (machine executor on circleci) with docker compose up it does not work. pushing the db schema displays the error described above where it can't push the schema because the database does not exist (even though it should get created if it doesn't, which is what happens locally and on the docker step) Let me know if you need any other details :)
Oh wait I think I may have gotten two of those ebackwards.
Let me edit the message
Ok fixed :)
This is what outputs when it successfully works (which does the exact same steps as the step that doesn't) yarn run v1.22.5 $ yarn prisma db push --schema prisma/core/schema.prisma --accept-data-loss $ /home/circleci/project/repo/node_modules/.bin/prisma db push --schema prisma/core/schema.prisma --accept-data-loss Environment variables loaded from .env Prisma schema loaded from prisma/core/schema.prisma Datasource "db": PostgreSQL database "*******-core-local", schema "public" at "localhost:5432" PostgreSQL database *******-core-local created at localhost:5432 🚀 Your database is now in sync with your schema. Done in 122ms Running generate... (Use --skip-generate to skip the generators) Running generate... - Prisma Client ✔️ Generated Prisma Client (2.28.0) to ./prisma/core in 174ms
r
On CI when running on an Ubuntu VM (machine executor on circleci) with docker compose up it does not work
Could you share a minimal version of this setup if possible? I would like to try this out locally.
j
Ya, I'll see if I can put one together this mor I.
Morning.
💯 1
So on a minimal repo it seems to work, I will compare what I am doing differently and see if I can track down what is going wrong with our setup compare to this simple example https://github.com/yharaskrik/prisma-db-circleci-push
r
Is the database ready before you run
db push
?
j
I used https://www.npmjs.com/package/wait-port to ensure the port was available before pushing the schemas.
The error also seems to be saying it cannot find the db on the server not, cannot connect to the server, so that leads me to believe it is actually able to connect to the postgres server.
Maybe I need the
--force-reset
flag? https://github.com/prisma/prisma/issues/7440
But that doesn't explain why it works fine in docker and locally but not on ubuntu.
So the force reset flag does not help. There is clearly something else wrong with my environment in this specific repo because I cannot recreate it in a minimal repo.
Ok I fixed it but I am still a bit confused by the error. It was my fault as I did not copy the
.env
file from s3 prior to pushing the schemas, so the "right" db url wasn't loaded (thanks to adding
DEBUG="*"
prior to the command). That being said I am very confused by that error itself, I don't think it is very descriptive as to what the problem was and I am not sure where the DB url case from that is was "trying" to use before.
r
Yeah the error then seems misleading. It would be great if you could open an issue regarding the misleading error message and the reason it is displayed 🙂