Open lwoodson opened 1 year ago
Is there any way for the code to detect this situation and adapt for you? The proposed solution requires the user to have intimate details of the plugin's implementation details. By copying & pasting the current default command to make a couple tweaks, the user is "freezing" the command into their own codebase, and will miss out on any changes to the plugin. Is it just the local path that needs to be overwritten?
Using env variable and include more debug information. This was necessary for us at onramp as we run our builds inside docker containers. When we started having native dependencies, this resulted in the
serverless-ruby-package
plugin attempting to run docker containers inside docker containers.Docker in docker is a known and used operational pattern and can be enabled by mounting the docker socket from the host inside the container that will launch new containers. A side effect of this, however, is that mounts to the innermost container are not happening relative to its immediate parent container that spawned it. Rather, it needs to be against the filesystem on the outermost container host.
So the default command of:
Works if you are running on a top level container on a local development machine, but NOT on a nested container. This allows the above command to be overriden with the
SRP_DOCKER_COMMAND
env variable as we are here in our particular project:Unit Tests
Integration Tests