Code review comment for lp:~jimbaker/juju-jitsu/unit-test

> On Wed, Nov 14, 2012 at 1:10 PM, Benji York <email address hidden>wrote:
>
> > Thanks for this subcommand, Jim. Nicola and I have been using it to write
> > some tests (see a first cut at lp:~juju-gui/charms/precise/juju-gui/trunk).
> > A few remarks follow.
> >
> > The charm directory name has to be the same as the charm name itself,
> > which makes testing different branches difficult. Is revisiting that
> > requirement possible?
> >
>
> This is a core requirement to guard against errant charm authorship. Its
> not a jitsu check per se, but a juju core one. Its unlikely to be revisited
> imo, but #juju-dev would be the appropriate place to confirm that.

Correct, the test in jitsu test is only an extra check to avoid unnecessary test runs. I don't see this changing anytime soon, and if it does in juju, we can readily change jitsu test.

> > It seems to us that the exit code from each one of the *.test files should
> > be propagated and reported by the test subcommand (e.g., if any test
> > returns a non-zero then Jitsu should return non-zero).

I will add that in a future release, it sounds like a great feature.

> >
> > Bootstrapping from within the command either causes errors or times out:
> > one needs to bootstrap in advance and use the --no-bootstrap option.
> >
> > When accessing machines for log retrieval, rsync asks for a password for
> > ubuntu@localhost. We can not figure out what that password should be.
> >
>
> try setting up the key of your environment file as an authorized key for a
> user ubuntu.
>
> i assume based on the address that this is being tested with the local
> provider, which is a bit of an oddball compared to other providers as the
> default user isn't 'ubuntu' but whatever the user account is. ideally the
> test runner could distinguish this based on provider type and use the local
> provider user account. that would still need manual addition of the ssh key
> to authorized keys as the local machine is not cloud-init initialized.
> alternatively in the case of the local provider the testrunner eschews
> machine log collection in favor of just unit log collection which should
> still work as per other providers.

Based on discussion about this in #juju, I will do some additional work on the lxc provider support in the next release.