On Wed, Jun 22, 2016 at 9:59 PM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Jun 22, 2016 at 09:01:55PM +0200, Duy Nguyen wrote: > >> Which makes me think, could we use something like this to make sure >> people (on Linux) can test more obscure cases? Sometimes there are >> featues that require some dependencies that are not always present on >> the developer's machine (http server is a big one, locales come close >> second, then there will be lmdb and watchman in future...). With this, >> said developer can do a final test run in docker covering as much as >> possible. > > Neat idea. This should also cover some other distro-specific issues like > "what's your /bin/sh look like", etc. It's a lighter-weight alternative > to testing alternate distros in a VM. It's lighter-weight and also helps skip preparation. Everything is scripted, if you want distro X, it's just one command away. The VM way would require you to go through installation process with lots of clicking and typing (unless you go full cloud solution like OpenStack, not really suited for single dev use). It's not just distro-specific. Not every developer has enough stuff installed to run all tests. My machine is svn-free for example so I never run those tests. Same story for pcre (have it but not enable it in git...). We can try to run both gettext and no-gettext configuration... Devs still have to install docker this way, but at least i could keep my laptop "clean" from unwanted stuff and still be able to run lots of tests. > But I think most of the interesting cases are more exotic than > distro-to-distro. Things like HFS+ normalization, or weird shell > toolchains on proprietary Unixes (but maybe there are docker images for > those systems?). I don't follow docker closely, but if it's still a container technology (i.e. sharing host kernel) then different OSes are out of question. > So I dunno if it would prove that useful for day to day use or not. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html