On 01/24/2014 03:15 PM, Paolo Bonzini wrote:
Il 24/01/2014 18:04, Lucas Meneghel Rodrigues ha scritto:
Taking the provider definitions out of the version control systems
allows for this workflow:
1) You clone virt-test, bootstrap, it'll download the specified version
of the git repos defined in test-providers.d. So far, no changes from
submodules
2) If we're referencing master, we won't update the test provider until
you provide --update-providers flag. If you do, it'll be updated, and
*you don't have to mess with git commands*.
This is also the same with submodules, the "git submodule update" can be
run by virt-test not necessarily by the user.
If you had the submodules, they point out to a specific commit of that
submodule. So, to keep track of master, you have to manually go inside
the tree, update your submodule and commit the change.
The inconvenience is true, but the corresponding advantage is
reproducibility of results. Whenever you'll change the API for say
guest-hw.cfg, and this affects some "only" or "no" statement in the test
providers' own .cfg files, you will not be able to associate which
versions of tp-* will work with which versions of virt-tests.
The idea is to have virt-test releases to reference only test provider
tags. This way you can still have 'blessed' combinations of code repos.
For example, virt-test release 2014.03.10 would have this in its test
provider definition:
[provider]
uri: https://github.com/autotest/tp-qemu.git
ref: 2014-02-10
[generic]
subdir: generic/
[qemu]
subdir: qemu/
[openvswitch]
subdir: openvswitch/
Of course, this is similar to submodules, but with provider files, you
can just drop an additional file, outside version control and have the
system work.
...
Is there documentation for how to "initialize" the provider
repositories? Will "./run -t qemu" do just that?
I did write the rough specification of how a test provider looks like
here:
I'm more interested in how to use it (docs for --update-providers etc.)...
Sure, docs will have to be written anyway for all of this.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
