[Top][All Lists]
[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.