Dockerfile from template broken

[wzrdtales]

Describe the Bug

The dockerfile from the template has a lot of issues. Having fixed one by one, this last one makes no sense. Why would the docker build require access to the DB. Clearly completely misunderstood what containers are about.

13 27.64 [23:35:20] ERROR: Error: cannot connect to Postgres. Details: getaddrinfo ENOTFOUND pg
#13 27.64     err: {
#13 27.64       "type": "Error",
#13 27.64       "message": "getaddrinfo ENOTFOUND pg",
#13 27.64       "stack":
#13 27.64           Error: getaddrinfo ENOTFOUND pg
#13 27.64               at /app/node_modules/pg-pool/index.js:45:11
#13 27.64               at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
#13 27.64               at async h (/app/.next/server/chunks/9083.js:151:9649)
#13 27.64               at async Object.i [as connect] (/app/.next/server/chunks/9083.js:151:9891)
#13 27.64               at async bD.init (/app/.next/server/chunks/9083.js:277:7886)
#13 27.64               at async bG (/app/.next/server/chunks/9083.js:277:11051)
#13 27.64               at async Object.p [as generateStaticParams] (/app/.next/server/app/(frontend)/posts/page/[pageNumber]/page.js:2:8710)
#13 27.64               at async builtRouteParams (/app/node_modules/next/dist/build/static-paths/app.js:396:36)
#13 27.64               at async buildAppStaticPaths (/app/node_modules/next/dist/build/static-paths/app.js:366:25)
#13 27.64               at async /app/node_modules/next/dist/build/utils.js:925:79
#13 27.64       "errno": -3008,
#13 27.64       "code": "ENOTFOUND",
#13 27.64       "syscall": "getaddrinfo",
#13 27.64       "hostname": "pg"
#13 27.64     }

How is the docker container supposed to work?

Link to the code that reproduces this issue

123123

Reproduction Steps

123123

Which area(s) are affected? (Select all that apply)

db: postgres

Environment Info

123123

[github-actions[bot]]

Please add a reproduction in order for us to be able to investigate.

Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.

Why was this issue marked with the invalid-reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@latest -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.

Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

Useful Resources

• Reproduction Guide
• Contributing to Payload

[nlvcodes]

As far as I can understand, this is a Next.js limitation: https://payloadcms.com/docs/production/building-without-a-db-connection

You can use the experimental build commands included in the link above to prevent next from requiring access to the db at build time.

[denolfe]

@wzrdtales To add onto @nlvcodes , if your Next.js app is attempting to statically build pages, it would be expected that retrieving them from the DB is necessary. As you stated, this is quite unexpected and unconventional for anyone that has used Docker in any capacity previously.

To avoid this behavior, you should use output: 'standalone' to avoid this limitation. This is specified in the Docker section of the docs: here. Can you verify if you've done this already as part of the fixes you've performed locally?

[wzrdtales]

output standalone was already added, however it is not enough. This is a really deep hole to go down to make sure nothing ever tries to build something static.

However the whole sense of a headless cms is the capability to produce pre rendered static pages, but accessing a database is not a feasible way to do that. From the docs I can't immediately see a good approach to have both, the local api for dynamic rendering and the "external", rest or whichever other for static pre rendering from a CI job.

[wzrdtales]

So @denolfe what is the correct way to use payload? It doesn't seem like this really works with docker and is not ment to work with it right? If it is ment to work with it, how should this be approached. Right now a build will end up with an outdated state unless the CI env has any access to the actual data. As no CI will ever get access to a DB, there is a need to build this differently. And there seems to be no hybrid access scheme of sorts or is there any way to do this as intended? In short how is this supposed to work?

Also when there is a build version and you restart the container the site will be out of date and only updated once something changes in the backend, which is what we noticed now along the way. So I guess it is not a good idea to even build it? How should revalidation happen in that case?