I believe that I can create dependent builds, ie if a build completes then queue the test job, which could be assigned to a single slave. (This is off the top of my head so it may vary)
Travis On Mon, Jan 17, 2011 at 3:01 AM, Daniel Golle <[email protected]>wrote: > > > 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 >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
