Migrations in docker

[evanthegrayt]

Currently, if I make a migration for the dummy project, I have to docker-compose run app bash, cd test/dummy, and run bin/rails db:migrate. Surely there's a way to do this from docker-compose.yml. I tried adding && cd test/dummy && bin/rails db:migrate to the command, but it didn't seem to work.

[paranormalhacktivity]

I have learned that you can add the command property to the docker-compose.yml like so...

command: >
  bash -c "cd test/dummy && bin/rails db:migrate"

This is how I currently have it setup and it does work. It will run whenever and only when docker-compose up is executed, again this will only execute on a docker-compose up. This is important to note, because it will not run on docker-compose build. We may want to also include those commands in the Dockerfile so that it may get ran on either an up or a build.

I am, however, a little on the fence as to whether this is the best way to handle things. There is a pretty intense discussion about the purpose of the docker-compose.yml here. Users wanted there to be an onrun property that would execute commands any time docker-compose was ran but it is suggested by several of the docker-compose devs that the sole purpose of the docker-compose.yml is not for automation but strictly for the orchestration of containers. They suggest creating a Makefile or shell script. I believe that if we went that route we would just need to add something like this to the docker-compose.yml...

entrypoint: ./docker-entrypoint.sh

...and have the entrypoint script do all the things. I'm still a little fuzzy on whether the entrypoint gets ran on each docker-compose command execution. It's very possible that it only ever gets executed on an up. A cool little tidbit that I learned about the entrypoint property is that it will be prefaced to anything in command and therefore if your script accepts arguments you could set the script in entrypoint and add your arguments for it in command. This all seems like it might be overkill for what we're trying to accomplish, so maybe we just stick with using the command property and maybe being redundant and putting the commands in the Dockerfile as well. I don't really have a strong opinion on this. @evanthegrayt do you have any thoughts or opinions around this?

[evanthegrayt]

@hkn34 I have no strong opinions. I might, if we ever use docker for more than just running tests, or if I learn more about docker itself. But I'll defer to you, since I think you've dug a little deeper into docker than I have!

I will say that I tried the command way myself, but it didn't seem to work. But there is a 90% chance I was doing something wrong.

All that to say, I'm happy with however you want to try it!