Re: FW: Testing, systemd support, rfc5188, cleanups

On Fri, Jan 6, 2012, at 18:05, Fabian Keil wrote:
> "Will Manley" <[email protected]> wrote:
> >
> > The branches can be found at
> > https://github.com/wmanley/polipo/branches
> > 
> > To pull them try:
> > git pull git://github.com/wmanley/polipo.git automated-testing
> 
> I had a look at that, but it seems fairly GNU/Linux-specific to me.
> 
> It introduces dependencies on at least GNU make,

Presumably the GNU specific feature here are implicit rules.  This
should be fairly easy to fix.

> bash,

Hmm, this is another dependency that could be fairly easily transformed
into a dependency on any POSIX compliant shell.  Presumably this would
be acceptable.

> Linux's version of sendfile()

I guess I can replace this with a read/write loop.  It's a bit of a
shame as it will be more verbose but would be worth it if it makes it
more palatable to upstream.

> and systemd. I suspect the systemd dependency will
> be a show stopper for quite a few users.

For clarity this test stuff has no dependency on systemd.  What it does
have is a dependency on systemd support in polipo itself.  This does not
introduce a systemd dependency for polipo nor for the tests.

The reason behind adding systemd support was that, of the purposes of
sandboxing, we start a different polipo instance for each of our
applications.  This meant that we want each polipo instance to listen on
a different port and set the http_proxy environment variable
appropriately.  The solution we came up with is to have a little program
that will:
 1. Open the socket with and bind to a random free port on localhost and
    set the environment variable LISTEN_FDS="1"
 2. fork()/exec() polipo
 3. set environment variable http_proxy
 4. exec() our application.

This means we neither have to wait until polipo is up and running before
starting our application nor parse any polipo STDOUT output to get the
port number.  We thought we may as well make this socket passing systemd
compatible as it wouldn't hurt but we in fact neither use nor have
systemd installed.  Honestly I haven't even tried to see if the systemd
support actually works with systemd itself at all.

Once this support was added I decided to use it for the tests as well as
it helps with test sandboxing.  This is important for test isolation
where you might want to run the tests on a box which you can't make
guarantees about what the state of the rest of the system is (including
which ports are available).  As a side effect it's made the test http
server simpler as well as it doesn't need to have any code in it for
opening ports.

> Given that you are already using curl, I wonder if you considered
> leveraging curl's test framework instead of starting from scratch?

Wow, that stuff looks really cool.  We will have a look into this. 
Thanks.

> The tests currently obviously don't cover what your tests do,
> but could probably be extended with less effort than it would
> take to get the automated-testing branch working on the other
> platforms supported by polipo.

Certainly there is a lot of value in having the test be portable.  It
means that:
1. one can check the behaviour on many platforms and catch subtle issues
   that might only exhibit on certain platforms and
2. more importantly it makes the development process more inclusive and
   means that there are more eyes on fixing issues and adding more test
   cases.

Either way though these tests even in their current non-portable form
have value.  They have already uncovered and helped fix a issue that
seems to have existed in polipo since at least 2006.

We will try to make the tests more portable and investigate the curl
tests.

Thanks

Will

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox