La CI n'aurait jamais pu construire l'image du back-end
prisma generate fails with 'Cannot resolve environment variable: DATABASE_URL' when the CI image build never passes it as a build arg, even though generate never connects.
Le filet avait un trou
Le test, le journal d'audit, le scanner, la CI — couvrant moins que je ne le supposais.
En déboguant ce qui précède j'ai construit le vrai stage prod à partir de zéro et j'ai heurté une défaillance préexistante : prisma generate qui lève Cannot resolve environment variable: DATABASE_URL. Le workflow CI qui construit cette image ne passe jamais DATABASE_URL/DIRECT_URL comme arguments de build et ne l'a jamais fait.
prisma generate ne lit que le schéma et ne se connecte jamais, mais le chargeur de config exige quand même que la variable soit présente. Donc cette étape échouerait en CI exactement comme elle l'a fait en local, à chaque fois.
Plutôt que de router de vrais secrets par les arguments de build — ce qui intègre des identifiants dans l'historique des couches d'image, et les images sont scannées, récupérées et mises en cache dans des endroits que tu ne contrôles pas — j'ai mis des placeholders inoffensifs dans le stage builder, cadrés sur l'étape generate. Une variable de build qui n'existe que pour satisfaire un chargeur de config devrait être un placeholder dans le Dockerfile, pas un secret CI. Aussi un rappel que « le workflow existe et a l'air raisonnable » n'est pas « le workflow a réussi récemment ».