5 ms·
Fair point; I was speaking more toward the case of needing a rebuild any time your container gets changed, due to the change-on-run ethos of DevLab versus the
by TomFrost 11y ago
Fair point; I was speaking more toward the case of needing a rebuild any time your container gets changed, due to the change-on-run ethos of DevLab versus the change-on-build ethos of Compose.
But where cleanup really comes into play is when you have multiple tasks. You can specify multiple command paths in Compose, but each one will be a newly built image. With DevLab, you could `lab install` a node project, followed by a `lab lint`, or a `lab test`. You could `lab build` to compile your app at any time. And when you do this, whether it's the first time or the twenty-first time, overhead versus what you'd experience locally is just a second -- and the only image you have is your environment container. No build process, ever.
- ksafranski 11y agoDevLab also gives you the ability to switch containers at runtime (something that would require reconfig of compose). For example, if you're testing on node:0.12 and want to see if it works in node:4 you can simply run: 'lab test -f node:4' There's no additional overhead or cleanup, or modification of files.
- kanzure 11y agoSounds like you could get the same benefits by installing sshd into each container and using ssh to execute inside of a single container, rather than using docker/compose "commands". This would allow you to keep your `pip install` updates, and only when you run `docker-compose rm` would the changes be nuked. Would that fit the workflow you've been talking about? Thanks!