[Buildbot-devel] Manual Scheduler trigger?

Stephen Milner smilner at redhat.com
Wed Feb 4 15:46:45 UTC 2009

Hey Ian,

The way I had set this up was having 1 master (with 1 irc  bot) to 1 group. So ...

Master A
- SlaveBuild A1 \
- SlaveBuild A2 |--------> #chanA
- SlaveBuild A3 /

Master B
- SlaveBuild B1 \
- SlaveBuild B2 |--------> #chanB

and so on..

I'm sure there are other ways to make this setup, but that is how I did it :-).

----- Original Message -----
From: "Ian Peters-Campbell" <mahatmamanic at gmail.com>
To: "Stephen Milner" <smilner at redhat.com>
Cc: Buildbot-devel at lists.sourceforge.net
Sent: Tuesday, February 3, 2009 4:12:49 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Buildbot-devel] Manual Scheduler trigger?


Following your advice I've set up IRC on the buildserver (handy since the company wanted an internal IRC network anyhow.) I'm ready to start instantiating some IRC Bots, but I'm not seeing an easy way to limit the builders each IRC bot has access to. 

To clarify, what I would like to do is have a separate channel for each project/dev team here at the office, and have a bot capable of performing all of the builds for that specific project reside in the channel. The channel could then be locked to ensure that only team members could fire off builds, and the build results would alwas be listed in the appropriate channel. 

Is there an easy way through existing code to create bots with a subset of builders that would allow this, or will I need to extend the bot functionality to get that behavior? 


On Fri, Jan 30, 2009 at 1:21 PM, Stephen Milner < smilner at redhat.com > wrote: 

Hello Ian, 

The way I do manual builds with our dev teams is with the IRC bots. When a dev lead is ready to have something built they fire it off in IRC and it goes through whatever build/test/package/etc.. steps that are defined. 

Why not have two build targets .... one for internal team building (builds on all check ins and/or when developers say build) and one for cutting a release that pushes it up to the company wide repository? That way your not adding in build related data to check-ins. 

As of right now I believe there is only an XMLRPC interface to see status, but not to kick off new builds and things like that ... but that sounds like a good addition that could be done. 

----- Original Message ----- 
From: "Ian Peters-Campbell" < mahatmamanic at gmail.com > 
To: Buildbot-devel at lists.sourceforge.net 
Sent: Friday, January 30, 2009 4:01:58 PM GMT -05:00 US/Canada Eastern 
Subject: [Buildbot-devel] Manual Scheduler trigger? 

Does anyone have any advice regarding setting up manual triggers for Schedulers/Builders? During setup I would really like to get the kinks worked out of the system without spamming check-ins to our SVN repository, so if there was a good quick way to order the Buildmaster to fire off a particular Builder at will it would help. I guess I could swap in a PeriodicScheduler with a short period to test with, but if there's an easy way to trigger from the command line that would be preferable. 

On a related note, my final goal is to have continuous integration builds put together after each check-in, but for those to only be published to the development team for the particular project. I would then like a way to specify a "published" build that is packaged and placed on a company-wide server, and that notifies a wider portion of the dev team including PM and QA. My "best" ideas so far were to have either an SVN commit message tag which tagged the build as public, or a README/release notes file that was watched by a scheduler for the public release. I assume that others have dealt with similar issues, and I am wondering if anyone has suggestions as to the cleanest way to manage this? 


This SF.net email is sponsored by: 
SourcForge Community 
SourceForge wants to tell your story. 
Buildbot-devel mailing list 
Buildbot-devel at lists.sourceforge.net 

More information about the devel mailing list