[Buildbot-devel] update on the next release (and a suggestion)
niklaus.giger at member.fsf.org
Thu Dec 7 22:11:54 UTC 2006
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)
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,
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
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.
More information about the devel