Closed ShiraazMoollatjie closed 6 years ago
So it turns out that the underlying file system is playing a role here when using Docker Volumes. I have been using a virtualbox vm and the project was sitting on a vboxsf file system. So when attaching a volume in my docker compose scenario(?), it has been attaching to a vboxsf volume this whole time.
When I moved the project from the vboxsf filesystem to something else (whatever my home directory filesystem has, ext4 I think) then updates to the files worked as expected.
https://www.virtualbox.org/ticket/819?cversion=0&cnum_hist=70 is the link for more information
I don't think that this is a postgres image issue anymore, I will close this issue
I have a docker compose file that looks like this. (
postgres:alpine
is currently pointing at v10.3)The scripts folder looks like this:
The Problem
My workflow for this project is progressive, so I add some SQL initialization data on my host OS, run
sudo docker-compose down -v
and thensudo docker-compose up
. I did not update my user to not need the use of sudo for this scenario.When I update the
init.sh
file, then these updates are reflected each time I rundocker-compose up
. Theinit.sql
file however, only remembers the first "version" of this file. Any subsequent updates are ignored when runningdocker-compose up
.Things I tried
sudo docker-compose up --renew-anon-volumes --force-recreate
which also does not seem to help.sudo docker volume prune
. Does not helpsudo docker system prune
So the question is simply, how do I get content updates of
init.sql
to be recognized by my docker compose setup?? I don't understand why changes toinit.sh
is picked up but changes toinit.sql
are ignored?How to reproduce
docker-compose.yml
filescripts
folder with aninit.sh
andinit.sql
file. The sql script can be anything, but below is what I used. Theinit.sh
can have a bunch of echos.docker-compose up
docker-compose down -v
followed bydocker-compose up
init.sh
script runs and an outdated version ofinit.sql
runs!!