[Buildbot-devel] Extending ShellCommand

[Kirill Lapshin]

Brian,

>YES! That would be wonderful! I've played a little bit with making .debs (I
>have a simple one for my Petmail system) but I've never tried to do anything
>with init.d scripts. Are you using the whole dh_* scheme?
>  
>
I sent you private e-mail with my sources.

>Yes, take a look at the current CVS sources, because both sides of the wire
>have changed significantly (although the actual wire protocol remains pretty
>much the same).
>
>On the slave side, the remote "SlaveCommand" instances can run zero or more
>shell commands as they see fit (the CVS/SVN steps change their behavior
>depending upon whether they see an updatable working directory, for example).
>Each one is started by creating a new ShellCommand instance (with the command
>to run), and a Deferred is returned to let you hook a callback to fire when
>the command completes. Each command sends stdout/stderr status up to the
>master, where it all gets added to the same LogFile. There's a flag to set
>whether you want the ShellCommand to send the exit code (since you should
>only send it once), so if your SlaveCommand uses multiple ShellCommands then
>it should either send the 'RC' status itself or ask the last ShellCommand to
>do it.
>
>On the master side, each BuildStep can run zero or more RemoteCommands, each
>of which corresponds to exactly one SlaveCommand. The most common type (in
>fact the only one used) is the RemoteShellCommand, which creates a single
>LogFile that collects everything the SlaveCommand sends back.
>
>The status-reporting overhaul imposes the following scheme:
>
> Each Step gets a single box in the waterfall display. It may have multiple
> LogFiles. It has a single "color", a single "result" (SUCCESS, WARNINGS,
> FAILURE, SKIPPED), and a single "text" array of short strings. It also has a
> .text2 array of strings which are added to the overall build's .text .
>
> Each Build is made up of a series of Steps. The Build has an overall status,
> a "color", a .text array of strings, and (eventually) a list of LogFiles.
>
>
>Most of the BuildSteps derive from ShellCommand because there is a lot of
>reusable status-reporting code in it. If your command only runs one
>RemoteCommand then it should do what you need. The actual SlaveCommand that
>gets executed depends upon what the .cmd attribute contains when .start() is
>invoked: any kind of RemoteCommand will do (e.g. the CVS step uses a
>LoggedRemoteCommand("cvs", args) to invoke the CVS slavecommand).
>  
>
Thanks for a nice overview, sounds like a move in right direction. I 
guess I'll wait till next release, and made a second attempt then.

>Funny you should mention that, take a look at buildbot/status/mail.py . It
>only sends mail to a static list of recipients, but it's a start. Let me know
>if you can think of some handy features to add to it.
>
>  
>
Nice! Looking forward to take next release for a spin!

Features I can think of:

Have a mapping from username to e-mail address. Have an option to send 
e-mail to person who broke build and buildmaster only. Have an ability 
to send "build fixed" e-mails, i.e. when build status changes from 
failure to success. It would be nice to have some integration with 
unittests -- you can envision extracting a summary of failed unittests, 
but that's obviously more complicated and might require writing a 
special unittesting step, producing build results as xml, parsing it, 
etc. That goes way beyound e-mail scope.

--Kirill