Conversation
|
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
| - my-net | ||
|
|
||
| db_postgres: | ||
| image: postgres:15.4-bullseye |
There was a problem hiding this comment.
Compare behavior with using --pull in the build command, which would also sidestep the idempotency issue since the remote image would be favored over the local one.
There was a problem hiding this comment.
I see. So this statement is unnecessary, and docker/postgres/Dockerfile will anyway start from that image (postgres:15.4-bullseye) 👍
There was a problem hiding this comment.
Worse — this statement is harmful! It results in the built docker container to override the originally tagged/pulled image, which in turn is what causes the idempotency issue since we’re replaying the same steps on top of the built container instead of the base image.
| - my-net | ||
|
|
||
| db_postgres: | ||
| image: postgres:15.4-bullseye |
There was a problem hiding this comment.
I see. So this statement is unnecessary, and docker/postgres/Dockerfile will anyway start from that image (postgres:15.4-bullseye) 👍
What changed
Avoids committing Postgres build steps to tagged image.
Why
We were running into issues with the Postgres container where rebuilds wouldn't be idempotent. This was addressed in #1 by checking for idempotency issues, but that didn't address the core issue.
The core issue is that by specifying
imagein the docker compose file, we'd tag the built image as the sourcepostgres:15.4-bullseyeimage (docs).Test plan
Running
docker-compose build db_postgrestwice in a row shouldn't lead to any issues.