From duelin.markers at gmail.com Sat Sep 6 18:46:14 2008 From: duelin.markers at gmail.com (John D. Hume) Date: Sat, 6 Sep 2008 18:46:14 -0400 Subject: [Cruisecontrolrb-developers] aggregate info from past builds Message-ID: I was talking with Philippe Hanrigou this week about the untapped value of aggregating information from previous builds -- he showed me Hudson's cool (and funny) "yesterday's weather" icons -- and possibly working on some support for reporting on previous builds in ccrb. The thought was to create something that writes some basic information about each build to a database when it completes ("human" build id, pass/fail, start timestamp, elapsed time) and try to make it easy for anyone to add "columns" to that and add their own data. (Code coverage results are one obvious metric that's only really interesting when viewed as changes over time.) Then we'd need to incorporate some graphing capability and hack it into the dashboard somewhere. There are all kinds of unanswered questions including how a user would configure custom data collection and reports in her build. Are there any existing tools people are using to aggregate build data and report on it? (I.e., to what extent is this a solved problem?) Assuming we think there's a problem worth solving and can come up with a coherent approach, would there be interest in having these features as part of ccrb itself? The pros speak for themselves. The cons obviously include the dependency on some sort of database and all the install headaches that brings with it. I was thinking the simplest thing would be a sqlite db file sitting in each project folder, but even that would surely lead to lots of support requests. Ditto for the graphing library, potentially, though I'd lean towards something that uses Flash or even just JavaScript over generating images, so it would hopefully be less of an issue. Any thoughts on how to minimize the new dependecies? If we were going to try to make it a plugin, I think it would actually have to be two: a builder plugin for data collection and a Rails plugin to get things to show up in the UI. Offhand I can't think of a clean way to do that, but there are pretty obvious unclean ways. :) There's always the option of making it a fork, but I really don't like that idea because of the relatively large barrier to a user trying it out. Thoughts? Thanks. -hume. From thewoolleyman at gmail.com Sat Sep 6 19:13:11 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 6 Sep 2008 16:13:11 -0700 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: On Sat, Sep 6, 2008 at 3:46 PM, John D. Hume wrote: > If we were going to try to make it a plugin, I think it would actually > have to be two: a builder plugin for data collection and a Rails > plugin to get things to show up in the UI. Offhand I can't think of a > clean way to do that, but there are pretty obvious unclean ways. :) Why isn't there a clean way? Is it due to limitations in CCRB's plugin architecture? > > There's always the option of making it a fork, but I really don't like > that idea because of the relatively large barrier to a user trying it > out. Why is a fork a large barrier? If you fork from the thoughtworks github branch, all users need to do is download the automatically-generated github tarball, or use the URL for the branch to check out directly. This is no more complicated then downloading the latest build or checking out the master branch, just different locations. -- Chad From nate at natemurray.com Mon Sep 8 17:13:22 2008 From: nate at natemurray.com (Nate Murray) Date: Mon, 8 Sep 2008 14:13:22 -0700 Subject: [Cruisecontrolrb-developers] Ability for builds to pickup where they left off? Message-ID: <9c1993f20809081413y54a72e0fs22270f33d7eeb048@mail.gmail.com> Hey Guys, I've been using cruisecontrol.rb for more than automated testing. I've started using it as a general nightly task runner/logger/notification framework. With very little modification I've been able to use it as a glorified cron, in a sense. That said, I think I'm pushing cruisecontrolrb to its limits. I'm running about 20 processes that can take between 3-8 hours each to complete. Under this kind of load I'm finding the following happens: * Everything starts, builders spawn their processes, so far so good. * The load gets heavy, cruisecontrolrb parent process hangs. In order to start it up again, all of the builders must also be restarted. * Even though the builders are restarted, the processes they spawned (to actually do the work) still run. (This is good) * The process spawned by the builders finishes hours later (good) * The builder never knows that the process spawned finished. (Because it is now a "new" builder, b/c the original builder for that project was killed) (bad) * The builder sits in "incomplete" forever and never notifies "build_finished" etc. (bad) It makes sense why this is the way it is. My question is, could there be a better, more robust way? Is there a general interest in this sort of thing? My plan was to refactor it to the following: * When a particular build is about to "execute" (app/models/build.rb, line 32 in my version), it somehow writes out the pid of the process that is being executed. * When a builder boots up, it checks to see if the 'executing_pid' file exists. If it does, it considers itself to be "running" and then polls that pid to see if it is finished. * If the executing_pid file finishes, it then calls the typical "build_finished" callbacks (<-- problem here, how do we know the exit status of a random pid? how do we know if it failed?) * Everyone is happy, because builders can now survive a cruisecontrolrb crash. A couple questions: 1) Is this even a good idea? Does anyone have any suggestions as to a better way to approach this problem? (Any thoughts on how I can find out why cruisecontrol.rb is hanging in the first place?) 2) If I write it, is there a general interest in a patch for this? Thanks, Nate From alexey.verkhovsky at gmail.com Mon Sep 8 17:52:25 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Mon, 8 Sep 2008 15:52:25 -0600 Subject: [Cruisecontrolrb-developers] Ability for builds to pickup where they left off? In-Reply-To: <9c1993f20809081413y54a72e0fs22270f33d7eeb048@mail.gmail.com> References: <9c1993f20809081413y54a72e0fs22270f33d7eeb048@mail.gmail.com> Message-ID: <3945c4270809081452u5673b8f7q37e6c827aafbac69@mail.gmail.com> On Mon, Sep 8, 2008 at 3:13 PM, Nate Murray wrote: > I've been using cruisecontrol.rb ... as a > glorified cron, in a sense. Wow! :) Instinctively, my reaction is "why not use a real job scheduler?". If there is any reason why this is not the right question, you can certainly build something like that for yourself. It certainly is too much complexity for the core CC.rb. -- Alexey Verkhovsky From duelin.markers at gmail.com Tue Sep 9 21:44:40 2008 From: duelin.markers at gmail.com (John D. Hume) Date: Tue, 9 Sep 2008 21:44:40 -0400 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: > Why isn't there a clean way? Is it due to limitations in CCRB's > plugin architecture? I think so. Builder plugins don't get loaded in the web app process. That's why I said it might need to be two plugins (one builder, one plain Rails). > Why is a fork a large barrier? Because if someone has a working ccrb setup (particularly one that's been hacked up a bit (even more particularly if it's been hanging around since before ccrb was in git and has no clever distributed SCM to help with merging/rebasing)), I think they'll feel a lot warmer and fuzzier dropping something into a plugins folder than switching to a new version of the whole app. Unfortunately most teams don't bother keeping their installs up to date. If there's a feature or fix that's relevant to them, they'll do it. Otherwise it's wasted effort. (This is hopefully less the case with installs done since ccrb moved to git, but even when it's far less painful to upgrade, if the CI server ain't broke, and you haven't been keeping track of changes, you're flirting with disaster to try to "fix" it.) Anyway, what do people think about reporting on past builds? -hume. From thewoolleyman at gmail.com Tue Sep 9 21:52:56 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 9 Sep 2008 18:52:56 -0700 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: On Tue, Sep 9, 2008 at 6:44 PM, John D. Hume wrote: > Anyway, what do people think about reporting on past builds? Sounds like it would be useful. However, to fit in with the standard CCRB cross-platform philosophy, any persistence mechanism should probably be file-based, and not rely on a database. From duelin.markers at gmail.com Thu Sep 11 19:02:11 2008 From: duelin.markers at gmail.com (John D. Hume) Date: Thu, 11 Sep 2008 19:02:11 -0400 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: > However, to fit in with the standard > CCRB cross-platform philosophy, any persistence mechanism should > probably be file-based, and not rely on a database. SQLite is pretty darn cross-platform. What line does it cross? Thanks. -hume. -- http://elhumidor.blogspot.com/ From thewoolleyman at gmail.com Thu Sep 11 19:08:18 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 11 Sep 2008 16:08:18 -0700 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: On Thu, Sep 11, 2008 at 4:02 PM, John D. Hume wrote: >> However, to fit in with the standard >> CCRB cross-platform philosophy, any persistence mechanism should >> probably be file-based, and not rely on a database. > > SQLite is pretty darn cross-platform. What line does it cross? Dunno. I was just channeling Alexey. You'll have to get his thoughts... From alexey.verkhovsky at gmail.com Thu Sep 11 19:48:56 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Thu, 11 Sep 2008 17:48:56 -0600 Subject: [Cruisecontrolrb-developers] aggregate info from past builds In-Reply-To: References: Message-ID: <3945c4270809111648m63e5c467k9b67a0f719f9029b@mail.gmail.com> Just write a custom build notifier (like email_notifier.rb) and add it to your project in cruise_config.rb. This notifier gets a full-blown Build instance at the end of each build, and can write whatever it pleases to any data storage it wants. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com]