I don't believe there has to be a lot of communication with the
build-bot
Why not? I mean, it is not *much* communication bandwidth-wise, neither
does it have stringent latency requirements. But building on the same
machine that later orchestrates the test makes more sense than
distributing the images through the network, no?
I'd rather just not connect things which don't have to be. it could
create unneeded dependencies and break things which are already working
well. Distributing the images other the network is not that bad imho, as
they are relatively small and it happens through a well-defined
interface (http).
Wouldn't it be better to not reinvent the wheel, but add the interface
to the hardware build testbed to an already existing buildbot?
I still don't see any reason for starting this from scratch?
Your design looks very sound to me, but the thing is small enough to not
need any fancy runtime or OOP principles.
A configuration file with key/value pairs should do nicely, no? Also,
small modules in whatever language the buildbot uses should be fine.
What's more, you pretty much exclude people that don't fancy ruby by
this. Me for example ;)
buildbot is written in Python, which is just as nice as Ruby.
I had a look quick look at the code and concepts of buildbot.
As far as I got it, Buildbot generally assumes that the machine
(buildslave) performing a build can also perfom all the tests.
Getting done what I was thinking of would require to split the
buildslave role into buildslave and testslave(s), where each testslave
can only offer a certain set of possible tests (the set is defined by
the different hardware routers connected). Alternatively, a rule can be
added that only machine having a certain hardware-testbed connected to
it should perform a build. The qemu-target could be seen as a
fake-hardware testbed available to all buildslave.
Also buildbot is quite complex animal already, which makes it hard to
add big things to it.
If Ruby is a no-go for more people, I'd be ok with getting started with
Python.
However, to outline the design, I start creating lots of stubs in Ruby now.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
