3 ms·

Very good questions. Here are a few pointers: Podman runs rootless and avoids (some of) the problems with permissions this way. It's possible to mount the so

Very good questions. Here are a few pointers: Podman runs rootless and avoids (some of) the problems with permissions this way. It's possible to mount the source directory (when running a container) over the place you copy it to (when building it) so you can start a container once and rebuild and test inside it while you edit outside of it. I think that containers are a good reason to make a technical distinction between unit tests and integration tests. The former should work outside the container to facilitate quick development whereas the latter can rely on the environment the container provides. That setup saves a lot of headache for configuring paths and dependencies. Finally, i find it very important that building the software and executing the unit tests should be possible outside the container. This way you can always use your local setup, maybe after some tweaking. This tweaking is the (small) price everyone has to pay every now and then. That way the build environment doesn't run stale. Imagine developing software with a frozen tool stack packed into a container ten years ago. Because that's what happens when everyone just uses the image.

zokier 3y ago
> I think that containers are a good reason to make a technical distinction between unit tests and integration tests. The former should work outside the container to facilitate quick development whereas the latter can rely on the environment the container provides. That setup saves a lot of headache for configuring paths and dependencies. > Finally, i find it very important that building the software and executing the unit tests should be possible outside the container Bingo. Containers allow you to brush lot of issues under the rug and make picky software that has involved/specific requirements for its environment. I would recommend resisting on relying that too much and try to make the software flexible and with sane defaults so that running it outside the container is not huge pain. Yes, it might slow you down and you might miss out on some niceties, but the benefits imho are there in the long term.

zokier 3y ago

> I think that containers are a good reason to make a technical distinction between unit tests and integration tests. The former should work outside the container to facilitate quick development whereas the latter can rely on the environment the container provides. That setup saves a lot of headache for configuring paths and dependencies. > Finally, i find it very important that building the software and executing the unit tests should be possible outside the container Bingo. Containers allow you to brush lot of issues under the rug and make picky software that has involved/specific requirements for its environment. I would recommend resisting on relying that too much and try to make the software flexible and with sane defaults so that running it outside the container is not huge pain. Yes, it might slow you down and you might miss out on some niceties, but the benefits imho are there in the long term.