From alexey.verkhovsky at gmail.com  Thu Jan  3 11:46:40 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 3 Jan 2008 09:46:40 -0700
Subject: [Cruisecontrolrb-developers] where do plugins live?
In-Reply-To: <b18eecea0712301436g30708c99y30938f6370170b7@mail.gmail.com>
References: <b18eecea0712301436g30708c99y30938f6370170b7@mail.gmail.com>
Message-ID: <3945c4270801030846h344e8e2eia66cb04e34bf955@mail.gmail.com>

On Dec 30, 2007 3:36 PM, Jeremy Stell-Smith <jeremystellsmith at gmail.com> wrote:
> I'm working with a plugin script, and to my surprise, the growl & jabber
> notifiers live in both the ccrb repos & the ccrb-contrib repos.  So, the
> question is, where should they live?  Should all plugins (aside from built
> in ones like the e-mail notifier) live only in the ccrb-contrib repos?

I'd say, they should be in contrib.
The problem is: how do we handle plugin docs then?

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From thewoolleyman at gmail.com  Thu Jan  3 16:14:31 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 3 Jan 2008 14:14:31 -0700
Subject: [Cruisecontrolrb-developers] How about a config file to auto-create
	(or delete) projects?
Message-ID: <e3af97510801031314y213a63dfn3f565e194bf69ae1@mail.gmail.com>

Hi,

Would the developers be open to a feature which allowed you to have a
yaml config file to specify a set of project names and URLs which
would be auto-installed?

In our cruise.rb setup, I've set it up so that the project name
automatically determines the version of rails a project will run
against.  For example, myproject_rails_1-2-5 will run rails 1.2.5, but
myproject_rails_2-0-1 will run rails 2.0.1.  Exact same url/code,
there is just an ENV var automatically set by cruise config which
determines the gem version used by rails (via GemInstaller).

However, when I want to test against a new version, I have to manually
delete and recreate the project.  It would be nice to just have a
config file live in svn somewhere, edit it, and have the new project
automagically appear (and old unused ones deleted, optionally).

This could even live in the site config as a property if that's
better, I haven't thought a lot about the details yet.

Thx,
--Chad

From nclark at pivotallabs.com  Mon Jan  7 12:56:19 2008
From: nclark at pivotallabs.com (Neal Clark)
Date: Mon, 7 Jan 2008 09:56:19 -0800
Subject: [Cruisecontrolrb-developers] Patch to render only relative URLs
Message-ID: <bc4b8db60801070956q72c7cf9bx5f8003649cedf89f@mail.gmail.com>

Hello.

I am trying to proxy ccrb so I can run it on our local network but still
provide a public site to clients. This is impossible right now because, even
using mod_proxy_html to change the URLs myself, they get rewritten to
absolute URLs (on the local network address) with each AJAX call.

The patch I'm submitting makes ccrb only write relative URLs, which solves
my problem and shouldn't introduce any for you.

Thanks,
Neal Clark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20080107/7ce17949/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: relative_url-ccrb-1.2.1.diff
Type: application/octet-stream
Size: 7018 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20080107/7ce17949/attachment-0001.obj 

From alexey.verkhovsky at gmail.com  Mon Jan 28 12:10:40 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Mon, 28 Jan 2008 10:10:40 -0700
Subject: [Cruisecontrolrb-developers] How a long build log can kill the
	dashboard
Message-ID: <3945c4270801280910x67e3fdc2jc0cce768f2940821@mail.gmail.com>

I have a situation with RubyOnRails CI build right now, where [for
some irrelevant reason] the build log contains a lot of errors and is
nearly 3 Mb long.
LogParser#failures (that extracts build errors from the build log) is
executed on every hit of a build page, and running all those regexps
on a 3 million bytes string causes a dashboard process to grow to over
400 Mb of RAM, and take ~50 seconds to finish the page. And then, Ruby
never releases memory it no longer needs, so it stays at 400+ Mb
(until it's killed by the monitor). Yikes.

Suggestions of a good way to avoid that situation are most welcome.
Currently, I'm thinking of just preventing LogParser to process
anything bigger than, say, 100k.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

From thewoolleyman at gmail.com  Mon Jan 28 12:54:59 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 28 Jan 2008 10:54:59 -0700
Subject: [Cruisecontrolrb-developers] How a long build log can kill the
	dashboard
In-Reply-To: <3945c4270801280910x67e3fdc2jc0cce768f2940821@mail.gmail.com>
References: <3945c4270801280910x67e3fdc2jc0cce768f2940821@mail.gmail.com>
Message-ID: <e3af97510801280954y62abb7dcy698277844dbde6e5@mail.gmail.com>

On 1/28/08, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> Suggestions of a good way to avoid that situation are most welcome.
> Currently, I'm thinking of just preventing LogParser to process
> anything bigger than, say, 100k.

Yes, that sounds easiest.  I'd at least put out a warning somewhere if
that happens.

Or, you could split big files into bite-sized chunks (in memory or on
disk), then do the regexp on each chunk.

-- Chad