Re: Use docker for _some_ testing?
On Wed, Jun 22, 2016 at 9:59 PM, Jeff King 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use docker for _some_ testing?
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. 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?). So I dunno if it would prove that useful for day to day use or not. > +ROOT="$(realpath $(git rev-parse --show-cdup))" I tried running this as contrib/docker/run.sh, which complained here, because --show-cdup is empty. > +test "$(docker images --format='{{.Repository}}' $IMAGE)" = $IMAGE || \ > + build_$DISTRO My docker complained that it doesn't know --format. I guess I might just have an old one (it's whatever is in Debian unstable, which is 1.8.3). Not things you need to fix, but just comments for anybody else fiddling with it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use docker for _some_ testing?
Duy Nguyen writes: > The story started with my problem on Debian, which I didn't have and > didn't want to install a Debian VM just for that problem. So I made a > docker image with the following script. > > 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. > > Of course it can't cover everything. Different compiler versions are > out. OS-specific changes are out (but wine would be still good to test > some aspect of Windows port, or at least make sure it builds) > > Comments? Nice. > -- 8< -- > diff --git a/contrib/docker/locale.gen b/contrib/docker/locale.gen > new file mode 100644 > index 000..ef08e00 > --- /dev/null > +++ b/contrib/docker/locale.gen > @@ -0,0 +1,2 @@ > +is_IS.UTF-8 UTF-8 > +is_IS ISO-8859-1 > \ No newline at end of file > diff --git a/contrib/docker/run.sh b/contrib/docker/run.sh > new file mode 100755 > index 000..83e5679 > --- /dev/null > +++ b/contrib/docker/run.sh > @@ -0,0 +1,30 @@ > +#!/bin/sh > + > +die() { > + echo "$@" >&2 > + exit 1 > +} > + > +build_debian() { > + cat >Dockerfile <<-EOF > + FROM debian:latest > + RUN apt-get update && \ > + apt-get install -y libcurl4-gnutls-dev libexpat1-dev \ > + gettext libz-dev libssl-dev build-essential > + RUN apt-get install -y locales > + COPY locale.gen /etc/locale.gen > + RUN locale-gen > + RUN groupadd -r $(id -gn) -g $(id -g) && \ > + useradd -u $(id -u) -r -d "$HOME" -g $(id -g) -s /sbin/nologin > $(id -un) > + USER $(id -un) > + EOF > + docker build -t $IMAGE . || die "failed to build docker image" > +} > + > +DISTRO=debian > +IMAGE=git-$DISTRO-$(id -un) > +ROOT="$(realpath $(git rev-parse --show-cdup))" > + > +test "$(docker images --format='{{.Repository}}' $IMAGE)" = $IMAGE || \ > + build_$DISTRO > +docker run -it --rm -v "$ROOT":"$ROOT" -w "$(pwd)" $IMAGE bash > -- 8< -- > -- > Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html