I’ve contributed to the Octobox app (GitHub - octobox/octobox: 📮Untangle your GitHub Notifications). I’ve been using a weird system of using Docker. Instead of using it the normal way, I create my own custom Docker image for each Rails project that I’m on. When I log into my custom Docker container, I basically follow the same procedure that the people who rely on their host environments do.
I’m trying to learn the more conventional way of using Docker with docker-compose, but I’m having difficulty finding out how you’re supposed to run the test suite.
I’ve followed the instructions at octobox/INSTALLATION.md at master · octobox/octobox · GitHub . While I’ve been able to get the development environment working, I have not been able to figure out how I’m supposed to run the test suite with the docker-compose command. Exactly what is the command for running the test suite?
You said “When I log into my custom Docker container, I basically follow the same procedure that the people who rely on their host environments do.” Can you run the tests successfully that way?
Yes. However, I use just one Docker container that contains everything I need, including Ruby, Rails, Node.js, PostgreSQL, Redis, etc. I know that my way is crude, but it works. I can’t move on to the docker-compose way of doing things until I figure out all the issues that are stopping me.
IMHO “…, I use just one Docker container” is the first order of (your) business to get straighten out
Using containers with Rails is quite a feast - and an added bonus is that once set up you have next to zero footprint on your ‘own’ computer (that is a blatant lye ‘cause your code base needs to sit somewhere, and the docker images has to be in place too - but even that could be ‘clouded’)
Docker containers doesn’t really start to shining until you let them
That is - delegate delegate delegate - or: one container per “task”
You’ll have at least three containers spinning - again IMHO. An app container with the Puma webserver serving the Rails stuff, a database container for the Rails models to persist their data, and a container for a reversed NgINX proxy serving clients on 80/443 and forwarding the necessary requests to the ‘animal’ (Puma). Other container candidates are: Redis, Sidekiq, and memcached. Here are the observations by Cloud66 - https://blog.cloud66.com/containers-for-rails-developers-use-containers-while-staying-true-to-your-ror-roots/
Thanks, Walther, on the suggestion of adding a docker container specifically dedicated to running tests. (I personally don’t agree with the use of Guard, so I’d just run the shell and then enter the test commands when necessary.) Why isn’t this normally done?
But exactly what is the docker-compose command for running the test suite on Octobox? Every time I’ve tried to run the test suite with a docker-compose command, I get stopped in my tracks by an error message telling me that simplecov isn’t loading. For reasons I haven’t been able to figure out, the simplecov gem doesn’t get installed when I enter “bundle install” even though it’s in the Gemfile and Gemfile.lock. I even tried starting a Docker container to run an sh shell, and running “bundle install” didn’t install the simplecov gem.
On the ‘running of shells and entering information manually’ - I guess that defeats the purpose of Docker (which basically is to allow automation and optimise CPUsage
On simplecov - tried to do “gem install simplecov” from that docker shell of yours?
You also might be running into issues regarding transient layers in Docker; it’s really not expecting you to log in and run a few scripts to install dependencies.
It’s expecting you to do that in your Dockerfile. It’s entirely possible simplecov or whatever other gem you are using is simply being discarded when the container shuts down. When a container is started, docker creates a transient layer for the container for things like logs, etc. Anything that isn’t in a volume will be erased once the container stops running - it doesn’t save that transient layer on container exit.
For a first start, what I might try is this: setup everything in one box like you were before, but this time, do it all from the Dockerfile.
I think you might find that you will have a lot more success that way.