4 ms·
I may be wrong, but this > It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and the
by CoolCold 4y ago
I may be wrong, but this
> It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and then you go back to master only to find out nothing works.
ticks some boxes for me - author prefer/works best in solo mode, otherwise such change would be reviewed by team members, before being put into master branch.
- smoochy 4y agoI think you're not seeing the actual point. The review isn't solving the issue. If you have two branches with alternating environments and you switch back and forth between them, how do you suppose your Dockerfile would handle it? What if that change isn't as simple as switching the Ruby version, but "compile and install some software" or some obscure config changes? I mean, it would be breaking all of the time, you'd end up having two containers anyway and you'd be scratching your head as to how to switch between them easily.
- IanCal 4y agoYou just build it. I'm not sure I understand the issue. If you really want then just tag them, but building with a cache would be very quick when you swap.
- ParetoOptimal 4y agoI'm pretty sure everyone prefers "check out branch, run build command" to transparently do the right thing rather than mental book-keeping of "does the state of my docker container match the Dockerfile of my feature branch"?
- IanCal 4y agoYes, that would be "docker build". Or docker compose if you want to do more things and organise the volume mapping side/other dependencies. > does the state of my docker container match the Dockerfile of my feature branch" Why track the state of your docker container? Just build it.