Closed nwarwick closed 3 weeks ago
Hi,
Thanks for the contribution. What use case are you handling where running the app in Docker isn't sufficient?
Hi,
Thanks for the contribution. What use case are you handling where running the app in Docker isn't sufficient?
@nickjj My pleasure! First use case is that I didn't want to restrict developers on my application to using Docker if they didn't want to use it. The second is that the .yarnrc file was breaking the node modules installation on my Github action.
Given this project is meant to run in Docker, I'm not sure if it's worth adding that at the project level to support running things outside of Docker as an option.
You could probably use a build argument and adjust the Dockerfile to only copy in that .yarnrc
file if a build arg is defined, such as WITHOUT_DOCKER=true
or whatever you decide to name it. In that case it would be a local change within your project though, I'm not sure about adding that here.
Fair enough! Might be worth adding something to the README at the very least as the Github actions failing stumped me for a bit. I think Github actions are pretty popular these days.
This project uses GitHub actions by the way.
Here's the CI workflow which builds everything and runs the test suite: https://github.com/nickjj/docker-rails-example/blob/main/.github/workflows/ci.yml
@nickjj Ah cool I was wondering if there was a way to just run the actions within the Docker environment. Let me try that.
The issue here is the volume mount. Most CI platforms don't use a UID / GID of 1000 and if we try to volume mount the public assets with those permissions it gets a permission denied. In CI volumes for assets isn't important so I disabled them.
This PR prevents the impact of .yarnrc file when installing dependencies locally. Running
yarn install
outside of docker fails for me, due to where the .yarnrc file is setting thenode_modules
folder to be.