[Buildbot-devel] Reg. Buildslaves - Getting User action during buildprocess.

[Scott Lamb]

On Mar 29, 2007, at 4:25 AM, Vengatachalam, Sakthivel wrote:
> 4. tell the user to switch-on the target system (by default it will  
> be switched off, only after the build (step 1-3) and before the  
> test execution (step 5-8) it should be switched on, It is mandatory  
> – is purely a manual process), after that get the input from user;  
> whether to continue or abort the build (its important because many  
> of the times the target system will be busy in other process/ 
> activities)
Why not use a dedicated machine or virtualization instead? The thing  
about manual processes is that people don't really do them. buildbot  
makes a great continuous integration system - you check something in,  
it tells you if it worked or not, entirely on its own. You can  
completely forget about it until it tells you something's wrong. If  
you try a different model, I think you won't get much result for your  
hard work.

> I don’t know whether it uses a pseudo terminal for running builds  
> at build-slaves. If this is the case then I can use a yes/no dialog  
> cmd to prompt the user for action. But I don’t know how to prompt a  
> user in a virtual console or any other consoles. But the user  
> should decide whether to continue or abort the entire build process.
There's an option to create a pseudo-terminal, but you seem to think  
that means this prompt will appear on a screen where you can respond,  
and it doesn't. It's just a trick to get different buffering behavior  
than a straight pipe, entirely orthogonal to interacting with consoles.

If you are going to do this manual thing, you might try this:

* Have one Builder to do the first three steps, use FileUpload to  
save the kernel to the buildmaster, and send an email notification.

* Have a second Builder grab a file indicated by the revision number,  
then fire off steps 5-8 on the target. (Note this Builder must still  
use a buildslave which is different than the target system, as the  
TCP connection to the buildmaster must be open during the entire  
build, during which the target will be rebooting.)

* Either just use the "force build" page to fire off the second  
builder, or write a trigger that does it based on a reply to the  
email notification.

Doing it this way means that you never have a build waiting on user  
input, which has lots of advantages:

(1) the build timeout doesn't apply to your user input
(2) if they say no to a test run, they can change their minds  
later...even if another build has gone by
(3) it doesn't limit the concurrency. (currently buildbot can't be  
running two builds of the same Builder on the same buildslave  
simultaneously.)
(4) buildbot's estimated build time calculation isn't skewed by an  
unpredictable delay waiting for user reply

-- 
Scott Lamb <http://www.slamb.org/>