Vladi Stevanovic
09/28/2022, 1:45 PMJonathan Marbutt
10/03/2022, 11:53 PMShahid Mawji
10/14/2022, 12:48 PMAngel Muñoz
10/11/2022, 11:59 AMpackage.json
. In gitlab-ci.yaml,
the 3 steps are executed in this order:
1. Build (which includes generating the Prisma Client with the latest version of the schema)
2. Migrate
3. Deploy to GCP
In `gitlab-ci.yaml`:
build:
script:
...
- npm install
- npm run build
...
migrate:
script:
- npx prisma migrate deploy
...
deploy:
script:
...
- gcloud --project "$GCLOUD_PROJECT_ID" app deploy app.yaml
At first, we tried to solve it by adding npx prisma generate
to the build command from our `package.json`:
"scripts": {
"build": "npx prisma generate && tsc -p tsconfig.build.json",
...
However, this didn’t work either. Any ideas on what could be happening? GCP seems to cache the node_modules between consecutive deployments if nothing has changed in package.json, but adding the Prisma Client generation to the build script doesn’t solve the issue either…
-----------------------------------------------------------
EDIT (2022-10-13):
ℹ️ We sorted this out by versioning our package.json
. Some platforms such as GCP cache the node_modules folder between deployments where package.json
hasn’t changed at all (not the dependencies, the version or any other change). When you add versioning, your node modules are installed again on your remote GCP instance, and your Prisma Client will be generated.Tomás Vallotton
10/18/2022, 1:34 AMnpx prisma migrate deploy
from the inside of that same container I get a connection error. It is very strange because both processes are spawned with the same DATABASE_URL
environment variable. I've tried running it from a shell from the inside of the container, as well as doing it from a bash script at startup but nothing was worked for me so far. Am I doing something wrong?Tomás Vallotton
10/18/2022, 1:36 AMError: P1001: Can't reach database server at `sibico-postgres`:`5432`
Please make sure your database server is running at `sibico-postgres`:`5432`.
Yet all my queries in my web app work.Tomás Vallotton
10/18/2022, 1:38 AMTomás Vallotton
10/18/2022, 1:43 AMTomás Vallotton
10/18/2022, 1:44 AMTomás Vallotton
10/18/2022, 1:45 AMTomás Vallotton
10/18/2022, 1:45 AMLisa Mabley
10/18/2022, 6:26 PMNurul
10/19/2022, 12:03 PMMartin Zvonár
10/19/2022, 6:56 AMALTER TYPE "SomeType" RENAME VALUE 'OTHER' TO 'OTHER_PRIVATE';
ALTER TYPE "SomeType" ADD VALUE 'OTHER_TEAM' AFTER 'OTHER_PRIVATE';
Is there some downside to using these ALTER TYPE
statements over the workflow generated automatically by Prisma? Maybe some compatibility issues? I’m new to Prisma so I’m not sure what’s a better way. Thanks!Armando Quintananieves - ISO
10/20/2022, 3:57 PMDaniel
10/24/2022, 5:52 AMnode@worker:/$ node_modules/prisma/build/index.js migrate deploy
Prisma schema loaded from prisma/schema.prisma
Datasource "db": MySQL database "test-database" at "onprem-xtradb-cluster-haproxy.my-organization.svc.cluster.local:3306"
5 migrations found in prisma/migrations
Error: Percona-XtraDB-Cluster prohibits use of GET_LOCK with pxc_strict_mode = ENFORCING
0: migration_core::state::ApplyMigrations
at migration-engine/core/src/state.rs:185
database: Percona (mysql)
prisma & client: 4.2.1
I understand the error message, but is it possible to bypass it somehow?
Quite a few other projects are now running on this database instance and other orm's have no problems with migrations. What am I doing wrong?Xiaojiba
10/24/2022, 8:48 PM[22:05] sapi fast-qr.com-dockercompose $ docker compose build --no-cache
[+] Building 384.5s (14/25)
=> CACHED [internal] load git source <https://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@github.com/erwanvivi> 0.9s
=> [internal] load metadata for <http://docker.io/library/node:alpine|docker.io/library/node:alpine> 0.0s
=> CACHED [runner 1/15] FROM <http://docker.io/library/node:alpine|docker.io/library/node:alpine> 0.0s
=> CACHED [runner 2/15] WORKDIR /app 0.0s
=> [builder 3/6] COPY . . 1.2s
=> [runner 3/15] RUN addgroup -g 1001 -S nodejs 1.1s
=> [deps 2/5] RUN apk add --no-cache libc6-compat 1.9s
=> [runner 4/15] RUN adduser -S nextjs -u 1001 1.4s
=> [deps 3/5] WORKDIR /app 0.2s
=> [deps 4/5] COPY package.json ./ 0.2s
=> [deps 5/5] RUN npm install --frozen-lockfile 225.9s
=> [runner 5/15] COPY .env* ./ 0.6s
=> [builder 4/6] COPY --from=deps /app/node_modules ./node_modules 9.1s
=> ERROR [builder 5/6] RUN npx prisma generate 134.2s
------
> [builder 5/6] RUN npx prisma generate:
#0 3.869 Prisma schema loaded from prisma/schema.prisma
#0 134.0 Error: request to <https://binaries.prisma.sh/all_commits/461d6a05159055555eb7dfb337c9fb271cbd4d7e/linux-musl/libquery_engine.so.node.sha256> failed, reason: connect ETIMEDOUT 52.222.158.58:443
------
failed to solve: executor failed running [/bin/sh -c npx prisma generate]: exit code: 1
I have found that re-running just after works sometimes just fine:
[22:16] sapi fast-qr.com-dockercompose $ docker compose build --no-cache
[+] Building 768.7s (26/26) FINISHED
=> CACHED [internal] load git source <https://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@github.com/erwanvivi> 0.8s
=> [internal] load metadata for <http://docker.io/library/node:alpine|docker.io/library/node:alpine> 0.0s
=> CACHED [deps 1/5] FROM <http://docker.io/library/node:alpine|docker.io/library/node:alpine> 0.0s
=> CACHED [builder 2/6] WORKDIR /app 0.0s
=> [runner 3/15] RUN addgroup -g 1001 -S nodejs 1.0s
=> [builder 3/6] COPY . . 0.9s
=> [deps 2/5] RUN apk add --no-cache libc6-compat 2.1s
=> [runner 4/15] RUN adduser -S nextjs -u 1001 0.8s
=> [runner 5/15] COPY .env* ./ 0.4s
=> [deps 3/5] WORKDIR /app 0.2s
=> [deps 4/5] COPY package.json ./ 0.2s
=> [deps 5/5] RUN npm install --frozen-lockfile 212.9s
=> [builder 4/6] COPY --from=deps /app/node_modules ./node_modules 11.2s
=> [builder 5/6] RUN npx prisma generate 10.7s
=> [builder 6/6] RUN npm run build && npm install --omit=dev --ignore-scripts --prefer-offline 480.6s
=> [runner 6/15] COPY --from=builder /app/next.config.js ./ 0.2s
=> [runner 7/15] COPY --from=builder /app/public ./public 0.7s
=> [runner 8/15] COPY --from=builder --chown=nextjs:nodejs /app/.next ./.next 1.3s
=> [runner 9/15] COPY --from=builder /app/node_modules ./node_modules 9.6s
=> [runner 10/15] COPY --from=builder /app/package.json ./package.json 0.1s
=> [runner 11/15] COPY prisma ./prisma 0.4s
=> [runner 12/15] RUN echo -e '#!/bin/sh\n npx prisma migrate deploy && \\\n node_modules/.bin/next start 0.8s
=> [runner 13/15] RUN chmod +x start.sh 0.8s
=> [runner 14/15] RUN chown nextjs:nodejs start.sh 0.9s
=> [runner 15/15] RUN chown -R nextjs:nodejs node_modules/@prisma 2.1s
=> exporting to image 12.5s
=> => exporting layers 12.5s
=> => writing image sha256:2e5e83514dbfa0894cad69ada1ddbd6bf87f0f19957a28211b48a25570e0205b 0.0s
=> => naming to <http://docker.io/library/fast_qrcom-fastqr|docker.io/library/fast_qrcom-fastqr> 0.0s
I have found this issue :
https://prisma.slack.com/archives/CA491RJH0/p1653083645405259
Which is kinda not resolved, can you help me ?