monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] mainline unit tests fixed


From: Nathaniel Smith
Subject: Re: [Monotone-devel] mainline unit tests fixed
Date: Tue, 25 Mar 2008 19:08:44 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Mar 25, 2008 at 06:27:30PM -0400, Zack Weinberg wrote:
> On Tue, Mar 25, 2008 at 4:48 PM, Markus Schiltknecht <address@hidden> wrote:
> >  I've hopefully fixed the two tests, which were failing on mainline. The
> >  first, non_workspace_keydir, one was failing, because it expected no
> >  keys in the keydir. If you had some in $HOME/keys, it failed. I've
> >  solved this by creating an empty directory and setting $HOME to that.
> 
> Ick.  Why are we even looking at $HOME in the testsuite?  It's really
> important that the testsuite not touch *any* of the user's
> configuration, lest it come to depend on some state in there -- or
> worse, corrupt the user's setup.  (Imagine if at some point in the
> future we migrate to some other keydir format; we don't want the user
> testing a trunk build to have their older, system-installed version
> suddenly stop being able to read their private key!)

Yeah, touching $HOME is weird, we should be using --confdir or
whatever it's called... that said, setting HOME to something isn't
*too* crazy a way to sandbox the mtn-under-test.

But if we do go that way, we'd better set APPDATA too...

> >  The second one took me more than an hour, because my knowledge of the
> >  ssh_agent is pretty uhm.. non-existent. Anyway, it turned out, that
> >  removing "--ssh-sign=no" from safe_mtn() in lua-testsuite.lua did the 
> > trick.
> >  It looks like Stephen added that in revision d7b34554...  I cannot see
> >  any reason for that addition, so I've removed it again.
> 
> I asked for that to be added, for the same reason as above - we don't
> want the test suite touching the user's ssh agent any more than their
> .monotone directory.  Most of the tests do not have anything to do
> with the ssh agent and should not use it at all, hence --ssh-sign=no
> in safe_mtn().
> 
> The ssh_agent test case (and all other hypothetical tests that do need
> the agent) ought to spawn a private copy of the daemon and kill it
> when it's done.

The problem isn't spawning a private copy of the daemon, IIRC the
tests do that; the problem is that after spawning a private copy of
the daemon, we need a way to run the mtn binary that will actually be
willing to talk to the daemon :-).  That's part of why we have all the
different *mtn() functions, because different parts of the test suite
can accept more or less defaults.

Maybe in this case the right solution is to add an extra
--ssh-sign=yes to the agent tests, though -- will that override an
-ssh-sign=no given earlier on the command line?

-- Nathaniel

-- 
Electrons find their paths in subtle ways.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]