On Wed, Jun 20, 2012 at 08:47:52PM +0200, intrigeri wrote:
> bertagaz@??? wrote (20 Jun 2012 09:52:20 GMT) :
> > You mean we can't build Tails inside a kvm domain because then
> > virtualbox has trouble installing?
>
> No. Fortunately, Tails builds perfectly inside a KVM domain :)
>
> But, given:
> - we want to run our automated builds using Vagrant, which implies:
> the build system must have the VirtualBox kernel modules loaded
> - we want to run our automated tests using KVM (better supported by
> libvirt, USB 2.0 support), which implies: the testing system must
> have the kvm kernel module loaded
> - on a given system, one cannot load the "kvm" and "vbox*" kernel
> modules at the same time
>
> => the testing and build systems must be different systems.
>
> In practice, both the build and testing systems will likely be KVM
> domains running on a bare-metal host. We'll need nested virtualization
> enabled for kvm_intel on this bare-metal host.
Hmm, ok, I clearly needs to catch up what on have been discussed so far on
this topic. But I get the idea. :)
> > But well, basically all that this cucumber tests need are an iso
> > file, and its path can be configured by the ISO env variable as
> > stated in the README.
>
> > So I guess we can answer to your first question as ""where the tests
> > are run from" and update the documentation. :)
>
> Great! Thanks for clarifying :)
>
> Note: given we most probably want to run the tests that were in the
> Git repository at the very commit the ISO image was built from, either
> the source tree must be shared between the build system and the
> testing one, or information about the commit that was used to run the
> build must be passed from the former to the latter.
I might not have a sufficiently clear big pictures of all this setup. :)
On the automated build system at least, this commits will usually be the
last HEAD of a branch, aren't they? It will probably also be the case if
they are run on the developper system while working on a feature. Sure
HEAD is a commit, but well... :)
In the long run, we might want to keep the tests maintained in the same
git workflow than the rest of the code: each $feature tests are pushed in
the $feature/feature branch along with the concerned code, and get merged
with this branch, say in the "stable" branch in case of a release for
example, with the rest of the feature code.
Given new features in Tails are usually developed in a "feature/foo"
branch, we can also use cucumber's tags and tag tests according to the
feature branch name they are related to.
This way we'll be able to start only the dedicated tests quite
programmatically. Cause we might not want to run all the test suite
everytime someone work on a feature (either on the build machine, or on
the developper system), but still from time to time check it doesn't break
the global test suite. We could also use a tag "release".
We might also have to consider that using sikuli for tests means hosting
images, possibly more and more as the tests number grows, and the Tails UI
changes. In the long term that means more and more binary data in the
Tails repo. We can also decide to host them appart from the code.
Does it sounds relevant, or am I missing something (maybe clarity once
again)?
bert.
N.B: as most of you have already other stuffs on top of their todo stack,
answers to this questions and on this threads more generally can for sure
be delayed. No hurry! :)
