[Buildbot-devel] update on the next release (and a suggestion)

[Niklaus Giger]

Am Donnerstag, 7. Dezember 2006 08:58 schrieb Brian Warner:
<...>
> So something like FileDownload(source, dest, mode=0755) ? Sure, I'd accept
> a patch for that, after 0.7.5 is out. Don't write it just yet, as I'll
> probably be changing FileDownload a little bit before the release, but as
> soon as 0.7.5 is cut feel free to submit one.
Yes, that is what I am looking for. And I have time to wait.

> > And I would prefer to specify in a Shell step "./my_bash.sh", instead of
> > [ "/bin/bash", "my_bash.sh"].
>
> If my_bash.sh has the executable bit set, then command=["./my_bash.sh"]
> ought to work (assuming it has a #!/bin/bash line, of course).
Yes, that why I want to be able to specify the mode. The example above is just 
my current work around.
<..>
> Would it make sense for this test script that you want to download and
> execute on the slave instead be checked in to your source tree? I'd like to
> understand the use case a bit more before coming to a decision about
> whether to encourage or discourage string-based commands.
I do not have a need for string based commands. I just want to be able to 
download scripts and configuration. If you want to study my setup have a look 
at the (a little bit outdated) 
http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.pdf
The buildbot itself may be reached at http://ngiger.dyndns.org:8010/

The FileUp/Download commands are all what I need to be able to keep (backup in 
Subversion repository) all my test scripts, kernel/.config etc in one place 
(e.g. the master) and not distributed on several slaves. I have no write 
privilege (never asked for it neither) in the main Xenomai (realtime 
extension to the Linux kernel) repository.

Also I like to have a separate test installation for my buildbot. And with 
scripts/configs scattered over test/stable and different master/slaves I 
sometimes just got a little bit lost, which config file /scripts was already 
updated and which not.

Realtime kernel often have very specific (non public) HW, e.g. I am working in 
a industrial manufacturer for plastic injection machines, where machines 
costing (100k - 1M US$) are controlled by custom PPC405 based controller 
card. Upgrade cycles are quite long and we prefer to stick with known good 
release (unfortunately still a proprietary OS) for years.

The embedded people like to tweak their environment, as each project has 
different needs (e.g. no harddisk, only 4 MB of memory)
The whole setup till you can really test an embedded board involves a lot,
e.g. 
LinuxFrom Scratch (or a Debian debootstrag or ...)
Linux kernel source +
Xenomai patches +
probably board specific patches
a kernel config
Xenomai application code
optionally RTnet (another project using Xenomai for RealTime Networking), 
pulled in from another Subversion repository
Bash or BusyBox
a RootFileSystem
Ethernet and/or serial connection to the board
cross compilation (for various architectures)
Remotely actuated PowerOn switch

It took me quite a few weeks to get the buildbot started. Keeping it up to 
date with all the changes + trying to improve it + trying to cover more 
corner cases (unit test, system test) is quite time consuming, but helps to 
catch a few (but far from all) errors.

In short a lot of things which just were better not integrated in the main 
trunk. And till now my whole buildbot setup is not yet mature enough to be 
shared. Once I get more people interested into running their own slave and we 
are able to come up with common scripts to cover the different variants I 
have no objection into getting my stuff into the Xenomai code base. 

I think that the buildbot I am running is quite complex as it involves 
(remote) system testing. But I found no better tool, and Buildbot served me 
fine and I really appreciated how you integrated a lot of suggestions from 
the mailing list. And someday I will attack also the problem how to trigger a 
build when one of several code sources are needed for a single project. I 
think in this respect CruiseControl has some advantages and a colleague of 
mine is using successfully also. But it has neither distributed slaves nor 
a "try" feature. The last two features made me choose buildbot.

Best regards

-- 
Niklaus Giger