On 01/24/2014 02:50 PM, Paolo Bonzini wrote:
Il 24/01/2014 17:48, Lucas Meneghel Rodrigues ha scritto:
On 01/24/2014 02:42 PM, Paolo Bonzini wrote:
Il 09/01/2014 03:53, Lucas Meneghel Rodrigues ha scritto:
virt-test will have a subdirectory 'test-providers.d' that contains
definition
files, which are .ini files that encode information from a test
provider. Here's
an example structure of a test provider file:
Weren't .d directories kinda obsoleted?
Also, I know I'm late, but would it be possible to use git submodules
instead?
We did consider submodules, but we wanted a solution a bit more
flexible. For example, if people want to put virt-tests on a random
subdir of qemu.git, that would be possible with test providers, and it'd
be very awkward with only submodules.
Can you explain this more? I'm intrigued. :)
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*.
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.
This means you have to do a lot of house keeping by yourself. I must say
since virt-test.git became a submodule of autotest-client-tests.git, and
autotest-client-tests.git became a submodule of autotest.git, I feel
depressed every time I make a virt-test release and have to remember to
update the chain of references on the other repos higher up the stack.
But that may just be me being a less than competent maintainer.
Also, with test providers you can use non-git resources (say, you have a
bunch of tests under /usr/share/tests), which is more flexible than
having to create a git repo, and a new commit referencing that git repo.
I'm not sure you are convinced, but that's how we went while discussing
this.
Hypothetically, the two files currently in test-providers.d would be
replaced by a .gitmodules file like this one:
[submodule "qemu"]
path = test-providers/qemu
url = https://github.com/autotest/tp-qemu.git
subdirs = generic/ qemu/ openvswitch/
^ I did not know git submodules supported subdirs.
They don't, but you can add arbitrary keys to the .gitmodules file.
I believe it is fine using git submodules + test providers, should the
need arise.
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:
https://github.com/autotest/virt-test/wiki/RepositorySplitProposal
Although I'm writing a more 'final' spec, since we discussed and changed
a number of things since this document was written.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
