From hayafirst at gmail.com  Thu May  1 17:18:15 2008
From: hayafirst at gmail.com (Yi Wen)
Date: Thu, 1 May 2008 16:18:15 -0500
Subject: [Cruisecontrolrb-users] secure cruise control rb
Message-ID: <ee6f48c00805011418j1eb81e79kbcb99a8ec1f7d1fc@mail.gmail.com>

Hey,

Just want to know, what is the standard way to protect my cruise rb page
from being accessed from outside without a permission?

Thanks.

Yi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080501/343e43c2/attachment.html>

From ben at benburkert.com  Thu May  1 17:30:06 2008
From: ben at benburkert.com (Ben Burkert)
Date: Thu, 1 May 2008 16:30:06 -0500
Subject: [Cruisecontrolrb-users] Changes to source control and bug
	tracking
In-Reply-To: <13de14180804301608r4e53ad67sd1c0fd255585cec5@mail.gmail.com>
References: <3945c4270804281439k7f4ebb37o14dcb044bffdd45c@mail.gmail.com>
	<13de14180804301457v1c46bcbwb2adb3e2ed14f8c@mail.gmail.com>
	<3945c4270804301552sb5ab0c6g70c84dcc5485c3aa@mail.gmail.com>
	<13de14180804301608r4e53ad67sd1c0fd255585cec5@mail.gmail.com>
Message-ID: <13de14180805011430j781e6df4tdc44b57e5d3bf5bc@mail.gmail.com>

Can we get an ETA on git support?  There's a couple big projects that want
to use it.

-Ben

On Wed, Apr 30, 2008 at 6:08 PM, Ben Burkert <ben at benburkert.com> wrote:

> I assume you're talking about grit?  I don't think it has any C
> extensions, so you should be able to vendor it without a problem.
>
> -Ben
>
>
> On 4/30/08, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> >
> > On Wed, Apr 30, 2008 at 3:57 PM, Ben Burkert <ben at benburkert.com> wrote:
> >
> > > Does this mean ccrb will have git support in the official branch?
> >
> >
> > Oh, yes. We are a CI tool project without our own CI loop at the
> > moment, and we can'[t let it stay that way, can we?
> > By the way, it's really sad, but I couldn't simply merge in your fork
> > - can't have binary dependencies in a shrink-wrapped product.
> >
> >
> > --
> >
> > Alexey Verkhovsky
> > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
> > RubyWorks [http://rubyworks.thoughtworks.com]
> > _______________________________________________
> > Cruisecontrolrb-users mailing list
> > Cruisecontrolrb-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080501/91198737/attachment.html>

From thewoolleyman at gmail.com  Thu May  1 17:50:58 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 1 May 2008 14:50:58 -0700
Subject: [Cruisecontrolrb-users] secure cruise control rb
In-Reply-To: <ee6f48c00805011418j1eb81e79kbcb99a8ec1f7d1fc@mail.gmail.com>
References: <ee6f48c00805011418j1eb81e79kbcb99a8ec1f7d1fc@mail.gmail.com>
Message-ID: <e3af97510805011450q304d89c0m7d3c1dc770e6712f@mail.gmail.com>

put it behind a web server proxy with basic auth turned on...

On Thu, May 1, 2008 at 2:18 PM, Yi Wen <hayafirst at gmail.com> wrote:
> Hey,
>
> Just want to know, what is the standard way to protect my cruise rb page
> from being accessed from outside without a permission?
>
> Thanks.
>
> Yi
>
>
>
> _______________________________________________
>  Cruisecontrolrb-users mailing list
>  Cruisecontrolrb-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
>

From ketanpadegaonkar at gmail.com  Thu May  1 23:27:57 2008
From: ketanpadegaonkar at gmail.com (Ketan Padegaonkar)
Date: Fri, 2 May 2008 08:57:57 +0530
Subject: [Cruisecontrolrb-users] CruiseControlRb behind apache
Message-ID: <80E840CA-EDDB-49B5-8684-FB321F8F7A12@gmail.com>

I managed to find this in the archives, so far: http://www.nabble.com/Setting-up-CCRB-behind-apache-proxy-tt14016053.html#a14099749

Found a better alternative to doing this in my .htaccess instead of  
messing with the httpd.conf, in case someone is interested:
--- snip ---
RewriteEngine On

### for cruisecontrol
RewriteBase	/
RewriteRule    ^(.*)$	http://localhost:3333/$1  [P]

AuthType	Basic
AuthName	"Cruise's Restricted Files"
AuthUserFile	/var/www/.htpasswd
Require		valid-user
--- snip ---

However is there a better way for me to have cruise running under http://myserver/cruise 
  instead of rooting it at "/". mod_proxy only rendered the html if I  
did this because the stylesheets and javascripts were in "/javascript"  
and "/stylesheets" instead of "/cruise/javascript" and "/cruise/ 
javascipt".

Is there a way I could run cruise under /cruise when starting it up,  
so that my apache acts as a dumb proxy ?

Cheers,
Ketan Padegaonkar
http://swtbot.org/ - a functional testing tool for SWT/Eclipse


From will.sargent at gmail.com  Fri May  2 02:02:22 2008
From: will.sargent at gmail.com (Will Sargent)
Date: Thu, 1 May 2008 23:02:22 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
Message-ID: <b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>

On Wed, Apr 30, 2008 at 12:27 PM, Alexey Verkhovsky
<averkhov at thoughtworks.com> wrote:
> > When people check in files, occasionally CruiseControl will error out
>  > saying that there's a conflict in schema.rb.
>
>  schema.rb is auto-generated on every build. If you have it checked in, by
>  the time the build is over, you may have a locally changed schema.rb and
>  when CC.rb tries to run an update, it may end up with a conflict.
>
>  The "Rails Way" is to have schema.rb in svn:ignore, and build your database
>  from migrations.

That's what I thought as well.  Then I saw this:

http://dev.rubyonrails.org/changeset/8124

 	44	# Note that this schema.rb definition is the authoritative source
for your database schema. If you need
 	45	# to create the application database on another system, you
should be using db:schema:load, not running
 	46	# all the migrations from scratch. The latter is a flawed and
unsustainable approach (the more migrations
 	47	# you'll amass, the slower it'll run and the greater likelihood
for issues).
 	48	#
 	49	# It's strongly recommended to check this file into your version
control system.

So if you're SUPPOSED to check it into your version control system...
how do you manage it once it's there?

Will.

From t.lucas at toolmantim.com  Fri May  2 02:17:32 2008
From: t.lucas at toolmantim.com (Tim Lucas)
Date: Fri, 2 May 2008 16:17:32 +1000
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
Message-ID: <949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>

On 02/05/2008, at 4:02 PM, Will Sargent wrote:

> On Wed, Apr 30, 2008 at 12:27 PM, Alexey Verkhovsky
> <averkhov at thoughtworks.com> wrote:
>>> When people check in files, occasionally CruiseControl will error  
>>> out
>>> saying that there's a conflict in schema.rb.
>>
>> schema.rb is auto-generated on every build. If you have it checked  
>> in, by
>> the time the build is over, you may have a locally changed  
>> schema.rb and
>> when CC.rb tries to run an update, it may end up with a conflict.
>>
>> The "Rails Way" is to have schema.rb in svn:ignore, and build your  
>> database
>> from migrations.
>
> That's what I thought as well.

Well different people have different takes on the issue, but I know a  
bunch of the core team, as well as myself, use schema.rb as the  
definitive DB definition. Migrations are simply a tool to help update  
old versions of the database.

The "rails way", for what it counts, is to use schema.rb.

>  Then I saw this:
>
> http://dev.rubyonrails.org/changeset/8124
>
> 	44	# Note that this schema.rb definition is the authoritative source
> for your database schema. If you need
> 	45	# to create the application database on another system, you
> should be using db:schema:load, not running
> 	46	# all the migrations from scratch. The latter is a flawed and
> unsustainable approach (the more migrations
> 	47	# you'll amass, the slower it'll run and the greater likelihood
> for issues).
> 	48	#
> 	49	# It's strongly recommended to check this file into your version
> control system.
>
> So if you're SUPPOSED to check it into your version control system...
> how do you manage it once it's there?

If you've created and run a migration you'll have both the migration  
file and the new schema.rb to check-in. Nothing special about it, it  
simply represents the schema the code code current code is written  
against.

-- tim


From jeremystellsmith at gmail.com  Fri May  2 02:44:05 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Thu, 1 May 2008 23:44:05 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
Message-ID: <b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>

it's still a generated file, and will still introduce conflicts on a system
like cruise if you're running migrations on said system - because each time
you do, it will regenerate a new copy of the file.

I suppose you have a choice, you could

a) don't check in schema.rb - let ccrb do it's default thing, which is to
run migrations before each build

b) check in schema.rb - don't run all migrations on your cruise box,
instead, generate the test db directly from schema.rb each build

I'll leave the rake tasks you'll need to call for option b to you.  But,
when you have them, add this line to your cruise_config.rb file (either on
the server or in your project root)

      project.rake_task = 'my_brand_new_cruise_rake_task'

or

    project.build_command = 'rake db:... default'

that should do it.

Jeremy

PS. Good luck on finding the one true Rails Way that is clearly superior to
all other Rails Ways.

On Thu, May 1, 2008 at 11:17 PM, Tim Lucas <t.lucas at toolmantim.com> wrote:

> On 02/05/2008, at 4:02 PM, Will Sargent wrote:
>
>  On Wed, Apr 30, 2008 at 12:27 PM, Alexey Verkhovsky
> > <averkhov at thoughtworks.com> wrote:
> >
> > > When people check in files, occasionally CruiseControl will error out
> > > > saying that there's a conflict in schema.rb.
> > > >
> > >
> > > schema.rb is auto-generated on every build. If you have it checked in,
> > > by
> > > the time the build is over, you may have a locally changed schema.rb
> > > and
> > > when CC.rb tries to run an update, it may end up with a conflict.
> > >
> > > The "Rails Way" is to have schema.rb in svn:ignore, and build your
> > > database
> > > from migrations.
> > >
> >
> > That's what I thought as well.
> >
>
> Well different people have different takes on the issue, but I know a
> bunch of the core team, as well as myself, use schema.rb as the definitive
> DB definition. Migrations are simply a tool to help update old versions of
> the database.
>
> The "rails way", for what it counts, is to use schema.rb.
>
>   Then I saw this:
> >
> > http://dev.rubyonrails.org/changeset/8124
> >
> >        44      # Note that this schema.rb definition is the
> > authoritative source
> > for your database schema. If you need
> >        45      # to create the application database on another system,
> > you
> > should be using db:schema:load, not running
> >        46      # all the migrations from scratch. The latter is a flawed
> > and
> > unsustainable approach (the more migrations
> >        47      # you'll amass, the slower it'll run and the greater
> > likelihood
> > for issues).
> >        48      #
> >        49      # It's strongly recommended to check this file into your
> > version
> > control system.
> >
> > So if you're SUPPOSED to check it into your version control system...
> > how do you manage it once it's there?
> >
>
> If you've created and run a migration you'll have both the migration file
> and the new schema.rb to check-in. Nothing special about it, it simply
> represents the schema the code code current code is written against.
>
> -- tim
>
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080501/f471f7aa/attachment.html>

From alexey.verkhovsky at gmail.com  Fri May  2 02:48:53 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Fri, 2 May 2008 00:48:53 -0600
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
Message-ID: <3945c4270805012348v15079f78u53c37598fabd8836@mail.gmail.com>

On Fri, May 2, 2008 at 12:17 AM, Tim Lucas <t.lucas at toolmantim.com> wrote:
>  The "rails way", for what it counts, is to use schema.rb.

Oh well... then I guess it's the ThoughtWorks Rails Way to not check
in schema.rb (or any other files generated at build time)... it's an
opinionated continuous integration software. :)

On a more serious note, if you insist on having schema.rb in the
version control, you need to define a "cruise" Rake task such that
it's not regenerating that file during the CI build. Or tell CC.rb to
always make a clean checkout. Otherwise local changes and merge
conflicts will happen.

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

From thewoolleyman at gmail.com  Fri May  2 02:56:48 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 1 May 2008 23:56:48 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <3945c4270805012348v15079f78u53c37598fabd8836@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<3945c4270805012348v15079f78u53c37598fabd8836@mail.gmail.com>
Message-ID: <e3af97510805012356u59334f59u9df8874985dd811d@mail.gmail.com>

On Thu, May 1, 2008 at 11:48 PM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
> On Fri, May 2, 2008 at 12:17 AM, Tim Lucas <t.lucas at toolmantim.com> wrote:
>  >  The "rails way", for what it counts, is to use schema.rb.
>
>  Oh well... then I guess it's the ThoughtWorks Rails Way to not check
>  in schema.rb (or any other files generated at build time)... it's an
>  opinionated continuous integration software. :)

I ignore schema.rb too, for better or worse :)

Here's something from my colleague that may be helpful, even though I
haven't really followed this thread :)

http://pivots.pivotallabs.com/users/alex/blog/articles/305-collapsing-migrations

-- Chad

From duelin.markers at gmail.com  Fri May  2 12:48:04 2008
From: duelin.markers at gmail.com (John D. Hume)
Date: Fri, 2 May 2008 12:48:04 -0400
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
Message-ID: <ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>

Can someone explain why you would expect to see schema.rb conflicts if the
checked in migrations are in sync with the checked in schema.rb?  Wouldn't
you expect cruise to generate a schema.rb identical to the one checked in?


On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith <
jeremystellsmith at gmail.com> wrote:

> it's still a generated file, and will still introduce conflicts on a system
> like cruise if you're running migrations on said system - because each time
> you do, it will regenerate a new copy of the file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/73498069/attachment.html>

From bkimble at inc21.com  Fri May  2 12:57:06 2008
From: bkimble at inc21.com (Billy Kimble)
Date: Fri, 2 May 2008 09:57:06 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
	<ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
Message-ID: <AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>

There shouldn't be conflicts in that case.

There is a case where you may use migration 20, and then someone in  
your team will use migration 21, so when you make a new migration you  
will use 22. If the dev who used migration 21 did not check their  
stuff in yet, so as far as your schema goes, you're up to version  
22 ... but you're still missing migration 21 until that person checks  
it in.


On May 2, 2008, at 9:48 AM, John D. Hume wrote:

> Can someone explain why you would expect to see schema.rb conflicts  
> if the checked in migrations are in sync with the checked in  
> schema.rb?  Wouldn't you expect cruise to generate a schema.rb  
> identical to the one checked in?
>
>
> On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith  
> <jeremystellsmith at gmail.com> wrote:
> it's still a generated file, and will still introduce conflicts on  
> a system like cruise if you're running migrations on said system -  
> because each time you do, it will regenerate a new copy of the file.
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/2a6ffaab/attachment.html>

From averkhov at thoughtworks.com  Fri May  2 13:18:32 2008
From: averkhov at thoughtworks.com (Alexey Verkhovsky)
Date: Fri, 2 May 2008 12:18:32 -0500
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
Message-ID: <OFB0C7EB42.0AFBA569-ON8625743D.005F14AC-8625743D.005F14AF@thoughtworks.com>

-----cruisecontrolrb-users-bounces at rubyforge.org wrote: -----
> Can someone explain why you would expect to see schema.rb conflicts if
> the checked in migrations are in sync with the checked in schema.rb?

Indeed, 99% of the time it would generate the same schema.rb, and therefore
no conflicts will happen. But then someone manually creates an index in
their local dev environment, and accidentally checks in the resulting
schema.rb, without adding that index to migrations. Oops.

--
Alex


From jeremystellsmith at gmail.com  Fri May  2 13:20:54 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Fri, 2 May 2008 10:20:54 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
	<ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
	<AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>
Message-ID: <b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>

and don't forget, developers make mistakes...all the time.  if they didn't
there would be little point to a continuous integration system in the first
place.  what if I change a migration, then "forget to run it" before
checking in.  this is exactly what ci should protect you from, however, in
your case instead of just failing, ci will go into an error state that the
only way to fix is to log onto the box.

no good.

On Fri, May 2, 2008 at 9:57 AM, Billy Kimble <bkimble at inc21.com> wrote:

> There shouldn't be conflicts in that case.
> There is a case where you may use migration 20, and then someone in your
> team will use migration 21, so when you make a new migration you will use
> 22. If the dev who used migration 21 did not check their stuff in yet, so as
> far as your schema goes, you're up to version 22 ... but you're still
> missing migration 21 until that person checks it in.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. On May 2, 2008, at 9:48 AM, John D. Hume wrote:
>
> Can someone explain why you would expect to see schema.rb conflicts if the
> checked in migrations are in sync with the checked in schema.rb?  Wouldn't
> you expect cruise to generate a schema.rb identical to the one checked in?
>
>
> On Fri, May 2, 2008 at 2:44 AM, Jeremy Stell-Smith <
> jeremystellsmith at gmail.com> wrote:
>
> > it's still a generated file, and will still introduce conflicts on a
> > system like cruise if you're running migrations on said system - because
> > each time you do, it will regenerate a new copy of the file.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
>
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/c130cb45/attachment.html>

From duelin.markers at gmail.com  Fri May  2 14:22:45 2008
From: duelin.markers at gmail.com (John D. Hume)
Date: Fri, 2 May 2008 14:22:45 -0400
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
	<ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
	<AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>
	<b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>
Message-ID: <ce1ffa990805021122m7fd0b356r98981ba85864fd86@mail.gmail.com>

I guess we've never had this issue primarily because we rebuild the dev
database from scratch on every build and always check in with a rake task
does that before running specs and committing all modified files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/d6833371/attachment.html>

From t.lucas at toolmantim.com  Fri May  2 18:21:30 2008
From: t.lucas at toolmantim.com (Tim Lucas)
Date: Sat, 3 May 2008 08:21:30 +1000
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
	<ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
	<AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>
	<b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>
Message-ID: <FE87F5D5-7110-4CB6-8EC0-CF74676A8165@toolmantim.com>

On 03/05/2008, at 3:20 AM, Jeremy Stell-Smith wrote:

> and don't forget, developers make mistakes...all the time.  if they  
> didn't there would be little point to a continuous integration  
> system in the first place.  what if I change a migration, then  
> "forget to run it" before checking in.  this is exactly what ci  
> should protect you from, however, in your case instead of just  
> failing, ci will go into an error state that the only way to fix is  
> to log onto the box.
>
> no good.

though it'd be nice for this *not* to happen. Surely there's a way  
around it?

I haven't used CC.rb in some time, but the way I used to have it set  
up is that the production DB would be copied for CC.rb to test  
against, then migrations were run, then the tests. If the DB was  
borked after one check-in the next had a chance of fixing the  
migration as it'd rebuild the DB from production and rerun the  
migrations.

I don't like the idea of assuming your CC.rb schema is the same as  
production simply because you're rebuilding from migrations each time.

-- tim


From jeremystellsmith at gmail.com  Fri May  2 18:38:02 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Fri, 2 May 2008 15:38:02 -0700
Subject: [Cruisecontrolrb-users] Conflicts with schema.rb?
In-Reply-To: <FE87F5D5-7110-4CB6-8EC0-CF74676A8165@toolmantim.com>
References: <OF5F13468B.64EDDC2A-ON8625743B.006ADF06-8625743B.006ADF09@thoughtworks.com>
	<b2a849dd0805012302r6bcbf573x279cf5ec2036f711@mail.gmail.com>
	<949CF9CF-B30A-4968-A936-5DAE55352A1D@toolmantim.com>
	<b18eecea0805012344m785ad62ai547867a52ad7e0d7@mail.gmail.com>
	<ce1ffa990805020948w78d7f7d3n3cfae2f94ca6f04@mail.gmail.com>
	<AE3C1AF8-D68C-42E6-9F6A-A4332552A1E0@inc21.com>
	<b18eecea0805021020r217a307sc5492916dce7d100@mail.gmail.com>
	<FE87F5D5-7110-4CB6-8EC0-CF74676A8165@toolmantim.com>
Message-ID: <b18eecea0805021538o7ff7ac77g7d3f9647c69ba2b9@mail.gmail.com>

you just have to choose, either schema.rb is god, in which case don't run
migrations on cruise, or your migrations are god, in which case don't check
in your schema.rb

it's that simple

cc.rb depends on subversion, the problem here is that you can get subversion
confused and then cc.rb is stuck

On Fri, May 2, 2008 at 3:21 PM, Tim Lucas <t.lucas at toolmantim.com> wrote:

> On 03/05/2008, at 3:20 AM, Jeremy Stell-Smith wrote:
>
>  and don't forget, developers make mistakes...all the time.  if they
> > didn't there would be little point to a continuous integration system in the
> > first place.  what if I change a migration, then "forget to run it" before
> > checking in.  this is exactly what ci should protect you from, however, in
> > your case instead of just failing, ci will go into an error state that the
> > only way to fix is to log onto the box.
> >
> > no good.
> >
>
> though it'd be nice for this *not* to happen. Surely there's a way around
> it?
>
> I haven't used CC.rb in some time, but the way I used to have it set up is
> that the production DB would be copied for CC.rb to test against, then
> migrations were run, then the tests. If the DB was borked after one check-in
> the next had a chance of fixing the migration as it'd rebuild the DB from
> production and rerun the migrations.
>
> I don't like the idea of assuming your CC.rb schema is the same as
> production simply because you're rebuilding from migrations each time.
>
> -- tim
>
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080502/79060afd/attachment.html>

From fdehay at hotmail.com  Tue May  6 05:37:56 2008
From: fdehay at hotmail.com (Franck Dehay)
Date: Tue, 6 May 2008 11:37:56 +0200
Subject: [Cruisecontrolrb-users] Failing build is restarted again and again
	(manual request + Win32)
Message-ID: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>


Dear all,
 
I am a recent user of this great tool for rails development and I have an issue with version 1.3.0. Sorry if I duplicate the question but I have been over the whole mailing list archives and could not find any answer.
 
I have set up cruisecontrolrb on my home server (which runs WinXP, sorry, but it is better for the girlfriend to use than some linux distrib which I use on my laptop) to check on the dev of my ROR apps.
I have set up the cruisecontrolrb not to use the personal folder as it had right access problems so I set up the CRUISE_ROOT_DATA to d:\work\ccror
My project's builds do fail because I have been a bad boy and did not write too many tests and some migrations fail as well. I am setting cc to fix that!
 
The problem then is that I clicked on the Build now button to have it started and as expected, the build fails after 10 seconds but ccrb keeps on building it again an again (got 2900 builds overnights:)).
While investigating, I found a "build_requested" file in my project folder which I guess was created when I clicked the "build now" button. It seems that the default behaviour is for this file not to be deleted when the build fails. Is there a way to change this? I can stop the neverending build loop by deleting the "build_requested" file
 
Thanks again for this great tool! I have been an user of cc on other projects and this is much easier to use.
 
 
_________________________________________________________________
Votre contact a choisi Hotmail, l'e-mail ultra s?curis?. Cr?ez un compte gratuitement !
http://www.windowslive.fr/hotmail/default.asp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080506/0ab819da/attachment.html>

From usselmann.m at icg-online.de  Tue May  6 07:30:50 2008
From: usselmann.m at icg-online.de (Manfred Usselmann)
Date: Tue, 6 May 2008 13:30:50 +0200
Subject: [Cruisecontrolrb-users] Failing build is restarted again and
 again (manual request + Win32)
In-Reply-To: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
References: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
Message-ID: <20080506133050.a6014135.usselmann.m@icg-online.de>

Hi Franck,

On Tue, 6 May 2008 11:37:56 +0200
Franck Dehay <fdehay at hotmail.com> wrote:

> 
> Dear all,
>  
> I am a recent user of this great tool for rails development and I
> have an issue with version 1.3.0. Sorry if I duplicate the question
> but I have been over the whole mailing list archives and could not
> find any answer. I have set up cruisecontrolrb on my home server
> (which runs WinXP, sorry, but it is better for the girlfriend to use
> than some linux distrib which I use on my laptop) to check on the dev
> of my ROR apps. I have set up the cruisecontrolrb not to use the
> personal folder as it had right access problems so I set up the
> CRUISE_ROOT_DATA to d:\work\ccror My project's builds do fail because
> I have been a bad boy and did not write too many tests and some
> migrations fail as well. I am setting cc to fix that! The problem
> then is that I clicked on the Build now button to have it started and
> as expected, the build fails after 10 seconds but ccrb keeps on
> building it again an again (got 2900 builds overnights:)). While
> investigating, I found a "build_requested" file in my project folder
> which I guess was created when I clicked the "build now" button. It
> seems that the default behaviour is for this file not to be deleted
> when the build fails. Is there a way to change this? I can stop the
> neverending build loop by deleting the "build_requested" file

It es meant to be deleted by it seems not to work under windows. I had
the same problem and as a workaround modified app\models\project.rb
(around line 463):

  def remove_build_requested_flag_file
    #!!! MU change: build_requested_flag_file partially contains '\' instead of '/' under windows 
    #FileUtils.rm_f(Dir[build_requested_flag_file])
    FileUtils.rm_f(Dir[build_requested_flag_file.gsub('\\','/')])
  end

There are also other areas where path names contain a mixture of '\'
and '/' under windows.

HTH,
Manfred

From fdehay at hotmail.com  Tue May  6 11:50:21 2008
From: fdehay at hotmail.com (Franck Dehay)
Date: Tue, 6 May 2008 17:50:21 +0200
Subject: [Cruisecontrolrb-users] Failing build is restarted again and
 again (manual request + Win32)
In-Reply-To: <20080506133050.a6014135.usselmann.m@icg-online.de>
References: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
	<20080506133050.a6014135.usselmann.m@icg-online.de>
Message-ID: <BAY128-W4699F432DAA446A1541022D8D60@phx.gbl>


Hello Manfred,
 
Thanks a lot for your response! Seemed quite plausible that it would come from the fact I was using Windows!
 
I'll look in the code (thanks for the details) but I doubt I'll dare update it.
 
May be next release will sort this out, in the meantime I'll try not to push the button.
 
Regards
Franck > Date: Tue, 6 May 2008 13:30:50 +0200> From: usselmann.m at icg-online.de> To: cruisecontrolrb-users at rubyforge.org> CC: fdehay at hotmail.com> Subject: Re: [Cruisecontrolrb-users] Failing build is restarted again and again (manual request + Win32)> > Hi Franck,> > On Tue, 6 May 2008 11:37:56 +0200> Franck Dehay <fdehay at hotmail.com> wrote:> > > > > Dear all,> > > > I am a recent user of this great tool for rails development and I> > have an issue with version 1.3.0. Sorry if I duplicate the question> > but I have been over the whole mailing list archives and could not> > find any answer. I have set up cruisecontrolrb on my home server> > (which runs WinXP, sorry, but it is better for the girlfriend to use> > than some linux distrib which I use on my laptop) to check on the dev> > of my ROR apps. I have set up the cruisecontrolrb not to use the> > personal folder as it had right access problems so I set up the> > CRUISE_ROOT_DATA to d:\work\ccror My project's builds do fail because> > I have been a bad boy and did not write too many tests and some> > migrations fail as well. I am setting cc to fix that! The problem> > then is that I clicked on the Build now button to have it started and> > as expected, the build fails after 10 seconds but ccrb keeps on> > building it again an again (got 2900 builds overnights:)). While> > investigating, I found a "build_requested" file in my project folder> > which I guess was created when I clicked the "build now" button. It> > seems that the default behaviour is for this file not to be deleted> > when the build fails. Is there a way to change this? I can stop the> > neverending build loop by deleting the "build_requested" file> > It es meant to be deleted by it seems not to work under windows. I had> the same problem and as a workaround modified app\models\project.rb> (around line 463):> > def remove_build_requested_flag_file> #!!! MU change: build_requested_flag_file partially contains '\' instead of '/' under windows > #FileUtils.rm_f(Dir[build_requested_flag_file])> FileUtils.rm_f(Dir[build_requested_flag_file.gsub('\\','/')])> end> > There are also other areas where path names contain a mixture of '\'> and '/' under windows.> > HTH,> Manfred
_________________________________________________________________
Avec Hotmail, vos e-mails vous suivent partout ! Mettez Hotmail sur votre mobile !
http://www.messengersurvotremobile.com/?d=hotmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080506/3c538c5c/attachment.html>

From alexey.verkhovsky at gmail.com  Tue May  6 13:45:28 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 May 2008 11:45:28 -0600
Subject: [Cruisecontrolrb-users] Failing build is restarted again and
	again (manual request + Win32)
In-Reply-To: <20080506133050.a6014135.usselmann.m@icg-online.de>
References: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
	<20080506133050.a6014135.usselmann.m@icg-online.de>
Message-ID: <3945c4270805061045u6a7fffaev14da21e63fe2c88b@mail.gmail.com>

On Tue, May 6, 2008 at 5:30 AM, Manfred Usselmann
<usselmann.m at icg-online.de> wrote:
>  There are also other areas where path names contain a mixture of '\' and '/' under windows.

Can you please make a ticket in Lighhouse and list those places that
you know of? This sort of thing would be very easy to fix, and I'd
like to fit it for the next release, but noone with commit right to
CC.rb is running CC.rb under Windows, so we need help to identify
those issues.

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

From alexey.verkhovsky at gmail.com  Tue May  6 17:53:43 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 6 May 2008 15:53:43 -0600
Subject: [Cruisecontrolrb-users] Git support - kinda works,
	have design questions
Message-ID: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>

As of now, I can create a project from Git repository, run a builder
on it, and even run the dashboard. Build pages look ugly because
build.label in git is very long, a bunch of unit tests is failing, and
I had to disable some functionality, namely displaying source control
errors in the dashboard.

SourceControl::AbstractAdapter#execute_with_error_log (formerly known
as Subversion::execute_with_error_log) had a bold assumption that any
command writing anything in stderr has failed. This is not true for
Git. Actually (and this really sucks), I even found a case where Git
command returns a non-zero exit code upon successful completion.
Namely, "git remote update" - I had to replace that with lower level
"git fetch origin" that seems to do the right thing. None of that is
documented behavior, as far as I can tell.

Anyhow, it works for some value of "works" now. ThoughtWorks IS needs
to punch a hole in the firewall so that ccrb.tw.com can talk to
RubyForge Git server. Once that is done, I am deploying the current
tip.

Meantime, there is one pretty important design decision to be made.
Commit id in distributed source control systems tends to be a very
long random hex string. So, our convention of using revision number as
 build labels doesn't work - neither for displaying, nor for ordering
builds.

If we still use those hashes for build labels, we'll need to order
builds by mtime of a build directory and display abbreviated build
labels instead of full ones. Or we need to generate our own build
numbers. Either way sucks, in its own special way. Does anyone have a
strong preference or a better idea?

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

From jsallis at gmail.com  Tue May  6 20:28:25 2008
From: jsallis at gmail.com (Jason Sallis)
Date: Tue, 6 May 2008 18:28:25 -0600
Subject: [Cruisecontrolrb-users] Git support - kinda works,
	have design questions
In-Reply-To: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
References: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
Message-ID: <0FAEDFDC-7577-4A45-9EEB-59AEA4A8E600@gmail.com>

Alex, have you considered using a shortened version of the revision  
hash for display? With git, you can do 'git rev-parse --short HEAD' to  
get a more readable but unique enough revision hash to id the build  
with. I'm not sure if mercurial or other distributed vc systems have  
such an option, but it would work for git at least. Just a thought.

- Jason

On 6-May-08, at 3:53 PM, Alexey Verkhovsky wrote:

> As of now, I can create a project from Git repository, run a builder
> on it, and even run the dashboard. Build pages look ugly because
> build.label in git is very long, a bunch of unit tests is failing, and
> I had to disable some functionality, namely displaying source control
> errors in the dashboard.
>
> SourceControl::AbstractAdapter#execute_with_error_log (formerly known
> as Subversion::execute_with_error_log) had a bold assumption that any
> command writing anything in stderr has failed. This is not true for
> Git. Actually (and this really sucks), I even found a case where Git
> command returns a non-zero exit code upon successful completion.
> Namely, "git remote update" - I had to replace that with lower level
> "git fetch origin" that seems to do the right thing. None of that is
> documented behavior, as far as I can tell.
>
> Anyhow, it works for some value of "works" now. ThoughtWorks IS needs
> to punch a hole in the firewall so that ccrb.tw.com can talk to
> RubyForge Git server. Once that is done, I am deploying the current
> tip.
>
> Meantime, there is one pretty important design decision to be made.
> Commit id in distributed source control systems tends to be a very
> long random hex string. So, our convention of using revision number as
> build labels doesn't work - neither for displaying, nor for ordering
> builds.
>
> If we still use those hashes for build labels, we'll need to order
> builds by mtime of a build directory and display abbreviated build
> labels instead of full ones. Or we need to generate our own build
> numbers. Either way sucks, in its own special way. Does anyone have a
> strong preference or a better idea?
>
> -- 
> Alexey Verkhovsky
> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
> RubyWorks [http://rubyworks.thoughtworks.com]
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users


From thewoolleyman at gmail.com  Tue May  6 20:43:13 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 6 May 2008 17:43:13 -0700
Subject: [Cruisecontrolrb-users] Git support - kinda works,
	have design questions
In-Reply-To: <0FAEDFDC-7577-4A45-9EEB-59AEA4A8E600@gmail.com>
References: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
	<0FAEDFDC-7577-4A45-9EEB-59AEA4A8E600@gmail.com>
Message-ID: <e3af97510805061743v50839c1yb98fa98496cbfae0@mail.gmail.com>

On Tue, May 6, 2008 at 5:28 PM, Jason Sallis <jsallis at gmail.com> wrote:
> Alex, have you considered using a shortened version of the revision hash for
> display? With git, you can do 'git rev-parse --short HEAD' to get a more
> readable but unique enough revision hash to id the build with. I'm not sure
> if mercurial or other distributed vc systems have such an option, but it
> would work for git at least. Just a thought.
>
>  - Jason

This seems like a great solution, Jason.  I'd definitely avoid a
manually generated build ID - having the build ID tied directly to SCM
is one of the nice things about cc.rb.

From nick at ekenosen.net  Wed May  7 08:07:23 2008
From: nick at ekenosen.net (nicholas a. evans)
Date: Wed, 7 May 2008 08:07:23 -0400
Subject: [Cruisecontrolrb-users] Git support - kinda works,
	have design questions
In-Reply-To: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
References: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
Message-ID: <276ff9870805070507v122be1a0of47afd5370c0e938@mail.gmail.com>

On Tue, May 6, 2008 at 5:53 PM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
>  If we still use those hashes for build labels, we'll need to order
>  builds by mtime of a build directory and display abbreviated build
>  labels instead of full ones. Or we need to generate our own build
>  numbers. Either way sucks, in its own special way. Does anyone have a
>  strong preference or a better idea?

Personally, I'd strongly prefer generated build numbers, because they
actually *mean* something to humans, and mtime isn't very obvious and
is potentially fragile.  Then again, I also strongly prefer bazaar (or
mercurial) to git, and they both provide (branch-specific) revision
numbers in addition to the (globally unique) revision id, so perhaps
my bias is not the same as a git lover's bias.  But surely by now
someone has written a git plugin/script that will tell you a branch's
current revision number?  It seems like a trivial thing to do.

Another option: you could use a concise date-based build number, e.g.
the output from:

 date "+%y-%j"
 08-128

Then the git fans won't be offended that you've used an "obviously
inferior" revision number instead of a precious SHA1 hash derivative.
;-P

-- 
Nick

From alexey.verkhovsky at gmail.com  Wed May  7 22:23:44 2008
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 7 May 2008 20:23:44 -0600
Subject: [Cruisecontrolrb-users] Git support - kinda works,
	have design questions
In-Reply-To: <276ff9870805070507v122be1a0of47afd5370c0e938@mail.gmail.com>
References: <3945c4270805061453t24dfea1fhaa466d22529d0210@mail.gmail.com>
	<276ff9870805070507v122be1a0of47afd5370c0e938@mail.gmail.com>
Message-ID: <3945c4270805071923g406b57dlfb9fec4cf50a7440@mail.gmail.com>

On Wed, May 7, 2008 at 6:07 AM, nicholas a. evans <nick at ekenosen.net> wrote:
>  >  If we still use those hashes for build labels, we'll need to order
>  >  builds by mtime of a build directory and display abbreviated build
>  >  labels instead of full ones. Or we need to generate our own build
>  >  numbers.
>  Personally, I'd strongly prefer generated build numbers

In the latest checkin, we are abbreviating global changeset ids (long
random hex strings) for both Git and Mercurial to the first five
characters. It turns out that both Git and Mercurial allow you to
specify changesets in this way, so it is a meaningful label, problem
solved.

5 characters sounds like a short string. We thought about what happens
if two changesets have the same first five characters. First of all,
16^5 is just above a million, so chances of that actually happening
are not that big. And then, consequences are not that serious - it
will just create a new build with the .1 suffix, like it was a
rebuild.

We are also sorting builds by mtime of the build directory. Whether
this is a performance concern remains to be seen by testing on a
project with large number of builds.

Bottom line: Mercurial and Git support available from the master
repository (previously known as trunk) passes some tests and looks
usable by now. If you need it desperately enough to deal with
unreleased software, please try it out and see what happens.

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

From usselmann.m at icg-online.de  Thu May  8 03:00:36 2008
From: usselmann.m at icg-online.de (Manfred Usselmann)
Date: Thu, 8 May 2008 09:00:36 +0200
Subject: [Cruisecontrolrb-users] Failing build is restarted again and
 again (manual request + Win32)
In-Reply-To: <3945c4270805061045u6a7fffaev14da21e63fe2c88b@mail.gmail.com>
References: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
	<20080506133050.a6014135.usselmann.m@icg-online.de>
	<3945c4270805061045u6a7fffaev14da21e63fe2c88b@mail.gmail.com>
Message-ID: <20080508090036.57a74e83.usselmann.m@icg-online.de>

On Tue, 6 May 2008 11:45:28 -0600
"Alexey Verkhovsky" <alexey.verkhovsky at gmail.com> wrote:

> On Tue, May 6, 2008 at 5:30 AM, Manfred Usselmann
> <usselmann.m at icg-online.de> wrote:
> >  There are also other areas where path names contain a mixture of
> > '\' and '/' under windows.
> 
> Can you please make a ticket in Lighhouse and list those places that
> you know of? This sort of thing would be very easy to fix, and I'd
> like to fit it for the next release, but noone with commit right to
> CC.rb is running CC.rb under Windows, so we need help to identify
> those issues.

I have put it on my To-Do list, but it may take a few days until I
have enough time for it. I have a suspicion: Maybe it is just caused by
the fact that I specified the CRUISE_DATA_ROOT env variable in windows
format (with '\' as separator).

Franck Dehay, who also had the problem with the build_requested flag
not being removed mentioned that he as well used a CRUISE_ROOT_DATA
with backslashes: "... set up the CRUISE_ROOT_DATA to d: \work\ccror".

In this case the best fix would probably be if cc.rb would convert
CRUISE_DATA_ROOT automatically.

I also want to update my version to the latest trunk / master. The
problem is that the firewall here does not allow to connect to the GIT
port and it seems not to be possible to connect to a git repository on
rubyforge.org via http. There also seems to be no ready solution for
Windows to use a http proxy for GIT access...

Manfred

From fdehay at hotmail.com  Thu May  8 03:54:13 2008
From: fdehay at hotmail.com (Franck Dehay)
Date: Thu, 8 May 2008 09:54:13 +0200
Subject: [Cruisecontrolrb-users] Failing build is restarted again and
 again (manual request + Win32)
In-Reply-To: <20080508090036.57a74e83.usselmann.m@icg-online.de>
References: <BAY128-W536644CAD2843AAA9FE304D8D60@phx.gbl>
	<20080506133050.a6014135.usselmann.m@icg-online.de>
	<3945c4270805061045u6a7fffaev14da21e63fe2c88b@mail.gmail.com> 
	<20080508090036.57a74e83.usselmann.m@icg-online.de>
Message-ID: <BAY128-W2594461493D20E13B79CCFD8D00@phx.gbl>


Hello,
 
Following on Manfred's tip, I changed my env variable to /work/ccrob and the problem is gone.
The build_requested file is now properly deleted at the end of the build.
Thanks for this!
 
But now, I'll start a new thread on another problem on windows about custom build artifacts...
 
> Date: Thu, 8 May 2008 09:00:36 +0200> From: usselmann.m at icg-online.de> To: cruisecontrolrb-users at rubyforge.org> Subject: Re: [Cruisecontrolrb-users] Failing build is restarted again and again (manual request + Win32)> > On Tue, 6 May 2008 11:45:28 -0600> "Alexey Verkhovsky" <alexey.verkhovsky at gmail.com> wrote:> > > On Tue, May 6, 2008 at 5:30 AM, Manfred Usselmann> > <usselmann.m at icg-online.de> wrote:> > > There are also other areas where path names contain a mixture of> > > '\' and '/' under windows.> > > > Can you please make a ticket in Lighhouse and list those places that> > you know of? This sort of thing would be very easy to fix, and I'd> > like to fit it for the next release, but noone with commit right to> > CC.rb is running CC.rb under Windows, so we need help to identify> > those issues.> > I have put it on my To-Do list, but it may take a few days until I> have enough time for it. I have a suspicion: Maybe it is just caused by> the fact that I specified the CRUISE_DATA_ROOT env variable in windows> format (with '\' as separator).> > Franck Dehay, who also had the problem with the build_requested flag> not being removed mentioned that he as well used a CRUISE_ROOT_DATA> with backslashes: "... set up the CRUISE_ROOT_DATA to d: \work\ccror".> > In this case the best fix would probably be if cc.rb would convert> CRUISE_DATA_ROOT automatically.> > I also want to update my version to the latest trunk / master. The> problem is that the firewall here does not allow to connect to the GIT> port and it seems not to be possible to connect to a git repository on> rubyforge.org via http. There also seems to be no ready solution for> Windows to use a http proxy for GIT access...> > Manfred> _______________________________________________> Cruisecontrolrb-users mailing list> Cruisecontrolrb-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
_________________________________________________________________
Avec Hotmail, vos e-mails vous suivent partout ! Mettez Hotmail sur votre mobile !
http://www.messengersurvotremobile.com/?d=hotmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080508/4d438d12/attachment.html>

From fdehay at hotmail.com  Thu May  8 04:35:19 2008
From: fdehay at hotmail.com (Franck Dehay)
Date: Thu, 8 May 2008 10:35:19 +0200
Subject: [Cruisecontrolrb-users] Custom builds artifacts not visible (WIN 32)
Message-ID: <BAY128-W5146318C0495C2A26FA4FD8D00@phx.gbl>


Hello again,
 
Cruisecontrolrb works well now on my XP box but for the following problem:
I have set up rails_rcov so that I can generate code coverage automatically at every build.
Following the manual, I have a custom task that copies rcov output to a specific folder (d:\work\ccrob\artifacts)
I have set up the environment CC_BUILD_ARTIFACTS to /work/ccrob/artifacts using the tip given in another thread about manual build requests.
And the result is that there is nothing in the builds about code coverage (when the target folder is actually nicely updated).
Anybody has any idea about this?
 
My guess is that ccrb may create links in the builds (like the manual says "The build page includes links to every file or subdirectory found in the build artifacts directory.") and links may not work in XP.
Is it possible to ask ccrb to actually copy the target folder in the build one?
 
Thanks in advance
 
In the meantime, I did manually copy the result of the coverage to the build folder via a xcopy command in which I guessed the build folder partial name (~= CC_ROOT_DATA/projects/PROJECT/build-CC_BUILD_LABEL) but it would be better if the default behaviour was working fine in XP
 
Franck Dehay
_________________________________________________________________
Retouchez, classez et partagez vos photos gratuitement avec le logiciel Galerie de Photos !
http://www.windowslive.fr/galerie/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080508/14b12bc0/attachment.html>

From usselmann.m at icg-online.de  Thu May  8 10:51:05 2008
From: usselmann.m at icg-online.de (Manfred Usselmann)
Date: Thu, 8 May 2008 16:51:05 +0200
Subject: [Cruisecontrolrb-users] Custom builds artifacts not visible
 (WIN 32)
Message-ID: <20080508165105.6d0f09f6.usselmann.m@icg-online.de>

Hello Franck,

there is no Windows specific problem here. CC_BUILD_ARTIFACTS can not
be set by you but instead is set by CruiseControl pointing to its
current build log dir. So you need to retrieve the env var within your
build script or rake task and write your files to this directory. 

Regards,
Manfred

> Hello again,
 
> Cruisecontrolrb works well now on my XP box but for the following
> problem: I have set up rails_rcov so that I can generate code
> coverage automatically at every build. Following the manual, I have a
> custom task that copies rcov output to a specific folder (d:\work
> \ccrob\artifacts) I have set up the environment CC_BUILD_ARTIFACTS
> to /work/ccrob/artifacts using the tip given in another thread about
> manual build requests. And the result is that there is nothing in the
> builds about code coverage (when the target folder is actually nicely
> updated). Anybody has any idea about this?
 
> My guess is that ccrb may create links in the builds (like the manual
> says "The build page includes links to every file or subdirectory
> found in the build artifacts directory.") and links may not work in
> XP. Is it possible to ask ccrb to actually copy the target folder in
> the build one?
 
> Thanks in advance
 
> In the meantime, I did manually copy the result of the coverage to
> the build folder via a xcopy command in which I guessed the build
> folder partial name (~=
> CC_ROOT_DATA/projects/PROJECT/build-CC_BUILD_LABEL) but it would be
> better if the default behaviour was working fine in XP
 

From third-chance at gmx.de  Tue May 13 10:38:13 2008
From: third-chance at gmx.de (Avalon)
Date: Tue, 13 May 2008 16:38:13 +0200
Subject: [Cruisecontrolrb-users] Problem geting web interface to work
Message-ID: <20080513143813.217010@gmx.net>

Hi,

i have installed CruiseControlRB 1.3.0. With no project added the web interface at localhost:3333 looks find.

I have successfully added one of my projects (batch file which builds some c++ code) which is also building fine.

But the web interface is no more working - i get the following message "Errno::EINVAL in Projects#index".

I have attached a log (run with --trace) which describes the error with stack trace more detailed. As far as i can see the lock file "C:/Server/cruisedata/projects/myproject/builder.lock" exists.

Any help is highly appreciated...

Thank you,
Thomas
-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
-------------- next part --------------
Processing ProjectsController#index (for 127.0.0.1 at 2008-05-13 16:25:00) [GET]
  Parameters: {"format"=>"js", "action"=>"index", "controller"=>"projects"}
Rendering projects/index_js


ActionView::TemplateError (Invalid argument - C:/Server/cruisedata/projects/myproject/builder.lock) on line #1 of app/views/projects/_project.rhtml:
1: <div id="project_<%= project.name %>" class="project build_<%= project.last_complete_build_status %>">
2: <table class="project_pane">
3: <tr>
4: 

    #{RAILS_ROOT}/lib/file_lock.rb:36:in `flock'
    #{RAILS_ROOT}/lib/file_lock.rb:36:in `locked?'
    #{RAILS_ROOT}/lib/project_blocker.rb:7:in `blocked?'
    #{RAILS_ROOT}/lib/builder_plugins/builder_status.rb:84:in `builder_down?'
    #{RAILS_ROOT}/lib/builder_plugins/builder_status.rb:12:in `status'
    #{RAILS_ROOT}/lib/builder_plugins/builder_status.rb:20:in `fatal?'
    #{RAILS_ROOT}/app/models/project.rb:194:in `last_complete_build_status'
    #{RAILS_ROOT}/app/views/projects/_project.rhtml:1:in `_run_rhtml_47app47views47projects47_project46rhtml'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:326:in `send'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:326:in `compile_and_render_template'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:301:in `render_template'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:260:in `render_file'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:275:in `render'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:59:in `render_partial'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:58:in `benchmark'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:58:in `render_partial'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:73:in `render_partial_collection'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:71:in `each_with_index'
    #{RAILS_ROOT}/app/models/projects.rb:71:in `each'
    #{RAILS_ROOT}/app/models/projects.rb:71:in `each_with_index'
    #{RAILS_ROOT}/app/models/projects.rb:71:in `send'
    #{RAILS_ROOT}/app/models/projects.rb:71:in `method_missing'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:71:in `render_partial_collection'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:285:in `render'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:597:in `render'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:459:in `replace_html'
    #{RAILS_ROOT}/app/views/projects/index_js.rjs:1:in `__bind_1210688700_187000'
    #{RAILS_ROOT}/app/views/projects/index_js.rjs:0:in `__bind_1210688700_187000'
    #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/core_ext/object/extending.rb:44:in `[]'
    #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/core_ext/object/extending.rb:44:in `instance_exec'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:313:in `initialize'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:625:in `new'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/prototype_helper.rb:625:in `update_page'
    #{RAILS_ROOT}/app/views/projects/index_js.rjs:0:in `_run_rjs_47app47views47projects47index_js46rjs'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:326:in `send'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:326:in `compile_and_render_template'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:301:in `render_template'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:260:in `render_file'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:806:in `render_file'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:738:in `render_with_no_layout'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:863:in `render_without_layout'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:798:in `render_action'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:748:in `render_with_no_layout'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:747:in `silence'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:747:in `render_with_no_layout'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/layout.rb:256:in `render_without_benchmark'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:in `render'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:in `measure'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:50:in `render'
    #{RAILS_ROOT}/app/controllers/projects_controller.rb:9:in `index'
    #{RAILS_ROOT}/app/controllers/projects_controller.rb:9:in `call'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:135:in `custom'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:133:in `call'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:167:in `respond'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:161:in `each'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:161:in `respond'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/mime_responds.rb:105:in `respond_to'
    #{RAILS_ROOT}/app/controllers/projects_controller.rb:7:in `index'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in `send'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:1095:in `perform_action_without_filters'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/filters.rb:632:in `call_filter'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/filters.rb:619:in `perform_action_without_benchmark'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `measure'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:66:in `perform_action_without_rescue'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/rescue.rb:83:in `perform_action'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:430:in `send'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:430:in `process_without_filters'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/filters.rb:624:in `process_without_session_management_support'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/session_management.rb:114:in `process'
    #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:330:in `process'
    #{RAILS_ROOT}/vendor/rails/railties/lib/dispatcher.rb:41:in `dispatch'
    #{RAILS_ROOT}/vendor/rails/railties/lib/webrick_server.rb:113:in `handle_dispatch'
    #{RAILS_ROOT}/vendor/rails/railties/lib/webrick_server.rb:79:in `service'
    c:/programme/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
    c:/programme/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:155:in `start_thread'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start_thread'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:94:in `start'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:89:in `each'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:89:in `start'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start'
    c:/programme/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start'
    #{RAILS_ROOT}/vendor/rails/railties/lib/webrick_server.rb:63:in `dispatch'
    #{RAILS_ROOT}/vendor/rails/railties/lib/commands/servers/webrick.rb:59
    c:/programme/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__'
    c:/programme/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require'
    #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/dependencies.rb:495:in `require'
    #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/dependencies.rb:495:in `new_constants_in'
    #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/dependencies.rb:495:in `require'
    #{RAILS_ROOT}/vendor/rails/railties/lib/commands/server.rb:40
    c:/programme/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__'
    c:/programme/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require'
    script/server:42
    cruise:6:in `load'
    cruise:6:in `start'
    cruise:68:in `send'
    cruise:68
    cruise:67:in `chdir'
    c:/programme/ruby/lib/ruby/1.8/fileutils.rb:104:in `cd'
    cruise:67


Rendering ./script/../config/../vendor/rails/actionpack/lib/action_controller/templates/rescues/layout.rhtml (500 Internal Error)

From jacques at 2ia.net  Wed May 14 10:53:02 2008
From: jacques at 2ia.net (Jacques Couvreur)
Date: Wed, 14 May 2008 16:53:02 +0200
Subject: [Cruisecontrolrb-users] Dashboard says there's no project!
Message-ID: <1210776782.482afcce9337c@ssl0.ovh.net>

Hy,

At first, apologize for this tool that seems to be "agile" : simple at first but
useful ;o)

But I have the same problem than Dan !... and a very short night behind me ;o)

A question before : Does CC.rb-1.3.0 should work on SVN repository under Apache
httpd with authentication ?

*** My configuration ***
- OS : Windows XP
- SVN : Authentication access, via http, Apache HTTPD server
- Ruby : Instant Rails 2.0
- CC.rb : 1.3.0

*** My story ***
- Download, unzip into CC_HOME, open DOS consol into CC_HOME
- cruise add MYPROJECT -u http://... --username xxx --password yyy -> OK (svn
checkout and latest svn revision detected)
- cruise start -> The web page said that no project was found !
- cruise build MYPROJECT --trace -> ... "access denied"
- set CRUISE_DATA_ROOT=c:/temp/ (to remove any spaces in the default path
"documents and setting" ?!)
- cruise build MYPROJECT -> the build begin but failed as follow...

===========================================================
===========================================================

[info]  [2008-05-14 13:15:11] Builder for project 'MY_PROJECT' started
Logging to: C:/software/ruby/cruisecontrolrb-1.3.0/log/MY_PROJECT_builder.log
[debug] C:/tmp/cruisecontrolrb/projects/MY_PROJECT/work Chiroa$ svn
--non-interactive log --limit 1 --revision HEAD:1 --verbose --xml
[debug] C:/tmp/cruisecontrolrb/projects/MY_PROJECT/work Chiroa$ svn
--non-interactive update --revision 9
Build 9 started
[info]  [2008-05-14 13:15:15] Build 9 started
[debug]
dir : C:/tmp/cruisecontrolrb/projects/MY_PROJECT/work
command : ruby -e "require 'rubygems' rescue nil; require 'rake'; load
'C:/software/ruby/cruisecontrolrb-1.3.0/tasks/cc_build.rake'; ARGV <<
 '--nosearch' << '--trace' << 'cc:build'; Rake.application.run; ARGV.clear"
executed command : echo C:/tmp/cruisecontrolrb/projects/MY_PROJECT/work Chiroa$
ruby -e "require 'rubygems' rescue nil; require 'rake'; load 'C:/
software/ruby/cruisecontrolrb-1.3.0/tasks/cc_build.rake'; ARGV << '--nosearch'
<< '--trace' << 'cc:build'; Rake.application.run; ARGV.clear"
 >> C:/tmp/cruisecontrolrb/projects/MY_PROJECT/build-9/build.log && ruby -e
"require 'rubygems' rescue nil; require 'rake'; load 'C:/software/rub
y/cruisecontrolrb-1.3.0/tasks/cc_build.rake'; ARGV << '--nosearch' << '--trace'
<< 'cc:build'; Rake.application.run; ARGV.clear" >> C:\tmp\c
ruisecontrolrb\projects\MY_PROJECT\build-9\build.log 2>&1
exitstatus: 1
STDERR TAIL START

STDERR TAIL END
[debug]   ./script/../config/../lib/command_line.rb:146:in `verify_exit_code'
[debug]   ./script/../config/../lib/command_line.rb:95:in `e'
[debug]   ./script/../config/../lib/command_line.rb:71:in `execute'
[debug]   ./script/../config/../lib/command_line.rb:70:in `chdir'
[debug]   ./script/../config/../lib/command_line.rb:70:in `execute'
[debug]   ./script/../config/../app/models/build.rb:31:in `run'
[debug]   ./script/../config/../app/models/build.rb:185:in `call'
[debug]   ./script/../config/../app/models/build.rb:185:in
`in_clean_environment_on_local_copy'
[debug]   ./script/../config/../app/models/build.rb:184:in `chdir'
[debug]   ./script/../config/../app/models/build.rb:184:in
`in_clean_environment_on_local_copy'
[debug]   ./script/../config/../app/models/build.rb:30:in `run'
[debug]   ./script/../config/../app/models/project.rb:309:in
`build_without_serialization'
[debug]   ./script/../config/../app/models/project.rb:286:in `build'
[debug]   ./script/../config/../app/models/project.rb:210:in
`build_if_necessary'
[debug]   ./script/../config/../app/models/polling_scheduler.rb:13:in `run'
[debug]   ./script/builder:79
[debug]   ./script/builder:78:in `catch'
[debug]   ./script/builder:78
[debug]   cruise:14:in `load'
[debug]   cruise:14:in `builder'
[debug]   cruise:68:in `send'
[debug]   cruise:68
[debug]  
C:/software/ruby/instant-rails-2.0/ruby/lib/ruby/1.8/fileutils.rb:121:in
`chdir'
[debug]  
C:/software/ruby/instant-rails-2.0/ruby/lib/ruby/1.8/fileutils.rb:121:in `cd'
[debug]   cruise:67
Build 9 FAILED
[info]  [2008-05-14 13:15:30] Build 9 FAILED

===========================================================
===========================================================


Does anybody have an idea ?

Dan, do you resolve your problem ?...

Thank by advance...

j.



> As a follow up, I've also tested against stock installs of InstantRails v1.7
> and v2.0 with the same reported outcome.
>
> I've insured that the ruby in v1.7 (v1.8.6) has been patched to level 111.
> IR v2.0 is already at patch level 111.
>
> So, I don't think that's the source of the problem...
>
> On Wed, Apr 30, 2008 at 12:31 PM, Alexey Verkhovsky <
> alexey.verkhovsky at gmail.com> wrote:
>
> > On Wed, Apr 30, 2008 at 1:28 PM, Dan McHarness <dan.mcharness at gmail.com>
> > wrote:
> > > I haven't made any configuration changes other than to repoint
> > > CRUISE_DATA_ROOT.
> >
> > Does it work if you do not define a custom CRUISE_DATA_ROOT?
> >
> > --
> > Alexey Verkhovsky
> > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
> > RubyWorks [http://rubyworks.thoughtworks.com]
> > _______________________________________________
> > Cruisecontrolrb-users mailing list
> > Cruisecontrolrb-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
> >


From joe.swatosh at gmail.com  Mon May 19 12:26:35 2008
From: joe.swatosh at gmail.com (Joe Swatosh)
Date: Mon, 19 May 2008 09:26:35 -0700
Subject: [Cruisecontrolrb-users] 2 Minor issues with 1.3.0 on windows
Message-ID: <ae6cb1100805190926w443328dja868be5517f23209@mail.gmail.com>

Hi all,

Lest I forget:

    Windows XP Pro SP2

    C:\CruiseControl\cruisecontrolrb-1.3.0>ruby --version
    ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]


We found two minor problems with CC.rb when trying to run on windows.

The first effects the Dashboard saying there is no project.  In
boot.rb we had to add a .gsub('\\','/') in #find_home when returning
the USERPROFILE.  (Unrelated to our problems, but possibly relevant to
some: at line 8 my system would not require the ':' as it is already
part of SYSTEMDRIVE).

Second, since our USERPROFILE starts C:\Documents and Settings\... the
we need additional quoting in CommandLine#execute around the :stdout
and :stderr options.  File.expand_path returns a string with embedded
spaces which would be choked on later.  We just wrapped those options
on lines 67 and 68 with quotation marks.

With those two changes, CC.rb is working great for us.  Thanks for
your efforts, and I hope these little notes will help other windows
users.

--
Joe Swatosh

From will.sargent at gmail.com  Tue May 20 00:45:10 2008
From: will.sargent at gmail.com (Will Sargent)
Date: Mon, 19 May 2008 21:45:10 -0700
Subject: [Cruisecontrolrb-users] IRC bot for cc.rb?
Message-ID: <b2a849dd0805192145r4fdb29ebk1b395a3a2c10b9ef@mail.gmail.com>

Hi all,

Don't suppose there's an IRC bot I can use (or repurpose) for cc.rb
notifications?

Will.

From thewoolleyman at gmail.com  Tue May 20 02:20:28 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 19 May 2008 23:20:28 -0700
Subject: [Cruisecontrolrb-users] IRC bot for cc.rb?
In-Reply-To: <b2a849dd0805192145r4fdb29ebk1b395a3a2c10b9ef@mail.gmail.com>
References: <b2a849dd0805192145r4fdb29ebk1b395a3a2c10b9ef@mail.gmail.com>
Message-ID: <e3af97510805192320q7c30963bwf6f48e45280b5a6@mail.gmail.com>

you could google for ones that generically proxy rss feeds...

On Mon, May 19, 2008 at 9:45 PM, Will Sargent <will.sargent at gmail.com> wrote:
> Hi all,
>
> Don't suppose there's an IRC bot I can use (or repurpose) for cc.rb
> notifications?
>
> Will.
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>

From will.sargent at gmail.com  Tue May 20 12:30:01 2008
From: will.sargent at gmail.com (Will Sargent)
Date: Tue, 20 May 2008 09:30:01 -0700
Subject: [Cruisecontrolrb-users] IRC bot for cc.rb?
In-Reply-To: <e3af97510805192320q7c30963bwf6f48e45280b5a6@mail.gmail.com>
References: <b2a849dd0805192145r4fdb29ebk1b395a3a2c10b9ef@mail.gmail.com>
	<e3af97510805192320q7c30963bwf6f48e45280b5a6@mail.gmail.com>
Message-ID: <b2a849dd0805200930w16e2c016kade7693dcd3305d3@mail.gmail.com>

> On Mon, May 19, 2008 at 9:45 PM, Will Sargent <will.sargent at gmail.com> wrote:
>> Hi all,
>>
>> Don't suppose there's an IRC bot I can use (or repurpose) for cc.rb
>> notifications?

> you could google for ones that generically proxy rss feeds...

It looks like rbot is going to be the winnah:

http://rubyforge.org/frs/shownotes.php?group_id=831&release_id=6311

If I get it working, I'll post details here. :-)

Will.

From bradbury at 8thlight.com  Wed May 21 11:01:22 2008
From: bradbury at 8thlight.com (Doug Bradbury)
Date: Wed, 21 May 2008 10:01:22 -0500
Subject: [Cruisecontrolrb-users] Fwd: One Build at a time
References: <57365890-B55C-4016-BD8E-8DD0D1303AF6@8thlight.com>
Message-ID: <3F29424A-0C4C-44EC-ADD0-61D079D5E5A6@8thlight.com>

>
> Hello CCrb users.
>
> Is there a way to configure Cruise Control rb to only build one  
> project at a time?
>
> I have two projects is two different repositories, and I don't want  
> their builds to overlap.
>
> Thanks,
>
> Doug Bradbury
> Software Craftsman
> 8th Light, Inc.
> blog.8thlight.com/doug


From jeremystellsmith at gmail.com  Wed May 21 14:45:54 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Wed, 21 May 2008 11:45:54 -0700
Subject: [Cruisecontrolrb-users] Fwd: One Build at a time
In-Reply-To: <3F29424A-0C4C-44EC-ADD0-61D079D5E5A6@8thlight.com>
References: <57365890-B55C-4016-BD8E-8DD0D1303AF6@8thlight.com>
	<3F29424A-0C4C-44EC-ADD0-61D079D5E5A6@8thlight.com>
Message-ID: <b18eecea0805211145h3d9f135ajaced593e7e86e92@mail.gmail.com>

yup, in your ~/.cruise dir, edit your site_config.rb file by uncommenting
the line about build serialization = true

On Wed, May 21, 2008 at 8:01 AM, Doug Bradbury <bradbury at 8thlight.com>
wrote:

>
>> Hello CCrb users.
>>
>> Is there a way to configure Cruise Control rb to only build one project at
>> a time?
>>
>> I have two projects is two different repositories, and I don't want their
>> builds to overlap.
>>
>> Thanks,
>>
>> Doug Bradbury
>> Software Craftsman
>> 8th Light, Inc.
>> blog.8thlight.com/doug
>>
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080521/1cf93b70/attachment.html>

From bradbury at 8thlight.com  Wed May 21 13:27:03 2008
From: bradbury at 8thlight.com (Doug Bradbury)
Date: Wed, 21 May 2008 12:27:03 -0500
Subject: [Cruisecontrolrb-users] One Build at a time
Message-ID: <44D83E3F-E0B0-485B-8DAE-69A702B41DEC@8thlight.com>

Hello CCrb users.

Is there a way to configure Cruise Control rb to only build one  
project at a time?

I have two projects is two different repositories, and I don't want  
their builds to overlap.

Thanks,

Doug Bradbury
Software Craftsman
8th Light, Inc.
blog.8thlight.com/doug

From manish at gslab.com  Fri May 23 06:41:48 2008
From: manish at gslab.com (Manish Sapariya)
Date: Fri, 23 May 2008 16:11:48 +0530
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
Message-ID: <48369F6C.2070901@gslab.com>

Hi All,
I have upgraded to verion 1.3. Our build output has huge
text in it and what I notice is that in 1.3 the I do not
see complete build.log.

Is there any flag to control this? I want to see the complete
build output because the last few lines has interesting output
about what part of build failed.

Thanks and Regard,
Manish

From manish at gslab.com  Sun May 25 02:32:09 2008
From: manish at gslab.com (Manish Sapariya)
Date: Sun, 25 May 2008 12:02:09 +0530
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
Message-ID: <483907E9.6000308@gslab.com>

Hi All,
I have upgraded to verion 1.3. Our build output has huge
text in it and what I notice is that in 1.3 the I do not
see complete build.log.

Is there any flag to control this? I want to see the complete
build output because the last few lines has interesting output
about what part of build failed.

Thanks and Regard,
Manish

From duelin.markers at gmail.com  Sun May 25 10:53:25 2008
From: duelin.markers at gmail.com (John D. Hume)
Date: Sun, 25 May 2008 10:53:25 -0400
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <483907E9.6000308@gslab.com>
References: <483907E9.6000308@gslab.com>
Message-ID: <ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>

Is the truncation in the build log file itself or just in the on-screen
rendering?

On Sun, May 25, 2008 at 2:32 AM, Manish Sapariya <manish at gslab.com> wrote:

> Our build output has huge
> text in it and what I notice is that in 1.3 the I do not
> see complete build.log.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080525/18432f70/attachment.html>

From thewoolleyman at gmail.com  Sun May 25 14:15:19 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 25 May 2008 11:15:19 -0700
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>
References: <483907E9.6000308@gslab.com>
	<ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>
Message-ID: <e3af97510805251115u2ca0886ft57ecaa3ddf2780d3@mail.gmail.com>

On Sun, May 25, 2008 at 7:53 AM, John D. Hume <duelin.markers at gmail.com> wrote:
> Is the truncation in the build log file itself or just in the on-screen
> rendering?

Pretty sure it's just the web ui.  I believe you can even click the
link at the bottom of the build page to see the full log?

From javadragon at gmail.com  Sun May 25 17:10:09 2008
From: javadragon at gmail.com (Lori Olson)
Date: Sun, 25 May 2008 15:10:09 -0600
Subject: [Cruisecontrolrb-users] Cruisecontroi footprint for a virtual
	machine installation
Message-ID: <b82056660805251410r4ec36e4cm65956ad0c6a0cc6@mail.gmail.com>

Does anyone have any feel for the requirements (disk space, memory, anything
else you can think of) of a virtual machine (say Centos Linux), set up as a
CruiseControl.rb build machine?

Regards, Lori
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080525/60227d32/attachment.html>

From thewoolleyman at gmail.com  Sun May 25 17:43:09 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 25 May 2008 14:43:09 -0700
Subject: [Cruisecontrolrb-users] Cruisecontroi footprint for a virtual
	machine installation
In-Reply-To: <b82056660805251410r4ec36e4cm65956ad0c6a0cc6@mail.gmail.com>
References: <b82056660805251410r4ec36e4cm65956ad0c6a0cc6@mail.gmail.com>
Message-ID: <e3af97510805251443k3e1ff5fbw9f3e37fcf4087856@mail.gmail.com>

Not much.  If you only run a single build, it is pretty much dependent
on the amount of memory you need for your build itself.  Disk space
can be controlled by proactively clearing out old build dirs/logs/etc.
 We've successfully run VMs of real rails app builds with only 256M of
RAM.  Of course, you want to keep an eye on that and ensure that
neither the virtual machine nor the host OS is swapping.

Bottom line, just try it out and keep a close eye on disk space and
memory on both the host OS and the virtual machine.

One caveat - Cruise.rb runs a separate builder process for each
project.  So, multiple projects - especially if you run them
concurrently - can really bog down the VM.  Even if you don't run them
concurrently, you still need more memory for each additional project.

Hope this helps.

Good Luck,
-- Chad

On Sun, May 25, 2008 at 2:10 PM, Lori Olson <javadragon at gmail.com> wrote:
> Does anyone have any feel for the requirements (disk space, memory, anything
> else you can think of) of a virtual machine (say Centos Linux), set up as a
> CruiseControl.rb build machine?
>
> Regards, Lori
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
>

From manish at gslab.com  Sun May 25 23:59:19 2008
From: manish at gslab.com (Manish Sapariya)
Date: Mon, 26 May 2008 09:29:19 +0530
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <e3af97510805251115u2ca0886ft57ecaa3ddf2780d3@mail.gmail.com>
References: <483907E9.6000308@gslab.com>	<ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>
	<e3af97510805251115u2ca0886ft57ecaa3ddf2780d3@mail.gmail.com>
Message-ID: <483A3597.70205@gslab.com>

Hi,
its in webui when I click the build log, thats when it shows the
partial logs. With 1.2 it shows the complete build log file when I
click build log on GUI. I have not calculated but if looks like there
is some size limitation on how much data from file to show, but I am
clueless as what causes that.

Please let me know if I can provide more info.
Thanks and Regards,
Manish

Chad Woolley wrote:
> On Sun, May 25, 2008 at 7:53 AM, John D. Hume <duelin.markers at gmail.com> wrote:
>> Is the truncation in the build log file itself or just in the on-screen
>> rendering?
> 
> Pretty sure it's just the web ui.  I believe you can even click the
> link at the bottom of the build page to see the full log?
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
> 

From jeremystellsmith at gmail.com  Mon May 26 04:02:35 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Mon, 26 May 2008 01:02:35 -0700
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <483A3597.70205@gslab.com>
References: <483907E9.6000308@gslab.com>
	<ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>
	<e3af97510805251115u2ca0886ft57ecaa3ddf2780d3@mail.gmail.com>
	<483A3597.70205@gslab.com>
Message-ID: <b18eecea0805260102o5d704219le281f155eb5dca64@mail.gmail.com>

okay, so contents_for_display in build.rb is what you want to look at, it
currently looks like this :

  def contents_for_display(file)
    return '' unless File.file?(file) && File.readable?(file)
    if File.size(file) < 100 * 1024
      File.read(file)
    else
      contents = File.read(file, 100 * 1024)
      "#{file} is over 100 kbytes - too big to display in the dashboard,
output is truncated\n\n\n#{contents}"
    end
  end

and I believe alexey added this code to protect against insanely long build
logs that could bring down the system.  what I would do is monkey patch
Build by doing something like this

class Build
  def contents_for_display(file)
    ...
  end
end

somewhere either in your site_config.rb file or if you only have one
project, even in your cruise_config.rb file.

I think we have the right behavior in the general case, but you have a
special case, and it's appropriate for you to customize the product to your
needs.

Jeremy

On Sun, May 25, 2008 at 8:59 PM, Manish Sapariya <manish at gslab.com> wrote:

> Hi,
> its in webui when I click the build log, thats when it shows the
> partial logs. With 1.2 it shows the complete build log file when I
> click build log on GUI. I have not calculated but if looks like there
> is some size limitation on how much data from file to show, but I am
> clueless as what causes that.
>
> Please let me know if I can provide more info.
> Thanks and Regards,
> Manish
>
>
> Chad Woolley wrote:
>
>> On Sun, May 25, 2008 at 7:53 AM, John D. Hume <duelin.markers at gmail.com>
>> wrote:
>>
>>> Is the truncation in the build log file itself or just in the on-screen
>>> rendering?
>>>
>>
>> Pretty sure it's just the web ui.  I believe you can even click the
>> link at the bottom of the build page to see the full log?
>> _______________________________________________
>> Cruisecontrolrb-users mailing list
>> Cruisecontrolrb-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>>
>>  _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080526/d465da50/attachment.html>

From thewoolleyman at gmail.com  Mon May 26 04:06:59 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 26 May 2008 01:06:59 -0700
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <b18eecea0805260102o5d704219le281f155eb5dca64@mail.gmail.com>
References: <483907E9.6000308@gslab.com>
	<ce1ffa990805250753r2aea509by591982478890b75d@mail.gmail.com>
	<e3af97510805251115u2ca0886ft57ecaa3ddf2780d3@mail.gmail.com>
	<483A3597.70205@gslab.com>
	<b18eecea0805260102o5d704219le281f155eb5dca64@mail.gmail.com>
Message-ID: <e3af97510805260106ud5f134eta12a6e93660f02cf@mail.gmail.com>

On Mon, May 26, 2008 at 1:02 AM, Jeremy Stell-Smith
<jeremystellsmith at gmail.com> wrote:
> and I believe alexey added this code to protect against insanely long build
> logs that could bring down the system.  what I would do is monkey patch

Seems like this should be exposed in the config file?  "insanely long"
is probably dependent on your environment...

-- Chad

From averkhov at thoughtworks.com  Wed May 28 12:05:48 2008
From: averkhov at thoughtworks.com (Alexey Verkhovsky)
Date: Wed, 28 May 2008 11:05:48 -0500
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
Message-ID: <OFF7BA5B16.72E87B0C-ON86257457.00586C15-86257457.00586C19@thoughtworks.com>

-----cruisecontrolrb-users-bounces at rubyforge.org wrote: -----
>> Is the truncation in the build log file itself or just in the on-screen
>> rendering?
>Pretty sure it's just the web ui.  I believe you can even click the
>link at the bottom of the build page to see the full log?

It is just in the UI. Rationale for this was provided by a situation where
several thousand tests were failing for the same reason, producing a huge
log file, and the dashboard was running out of memory trying to parse it.

The link at the bottom is not there yet, but surely is a good idea. I would
actually put it inside the message that says that the file was too long. It
would be even nicer if we displayed the first 100 Kb of the file, and had a
"See more" link at the end, that would serve the whole thing as a text
file, without parsing.

Send patches! :)

--Alex


From averkhov at thoughtworks.com  Wed May 28 12:13:41 2008
From: averkhov at thoughtworks.com (Alexey Verkhovsky)
Date: Wed, 28 May 2008 11:13:41 -0500
Subject: [Cruisecontrolrb-users] Cruisecontroi footprint for a
 virtual	machine installation
Message-ID: <OF6B8A8E50.5A9D65F5-ON86257457.005924C2-86257457.005924C4@thoughtworks.com>

> Does anyone have any feel for the requirements (disk space, memory,
anything else you can think of) of a virtual machine (say Centos Linux),
> set up as a CruiseControl.rb build machine?

On a couple of CC.rb installations I oversee, long living dashboard
processes tend to have RSS of about 40-50 Mb, and builder process are
around 35-40 Mb. MRI never releases memory back to the OS, so those are the
right numbers. Multiply by some safety factor and add whatever your build
process itself uses. 256 or 512 Mb should be it.

--Alex


From javadragon at gmail.com  Wed May 28 12:29:02 2008
From: javadragon at gmail.com (Lori Olson)
Date: Wed, 28 May 2008 10:29:02 -0600
Subject: [Cruisecontrolrb-users] Cruisecontroi footprint for a virtual
	machine installation
In-Reply-To: <OF6B8A8E50.5A9D65F5-ON86257457.005924C2-86257457.005924C4@thoughtworks.com>
References: <OF6B8A8E50.5A9D65F5-ON86257457.005924C2-86257457.005924C4@thoughtworks.com>
Message-ID: <b82056660805280929k1594102ck9e2dff294c1aee00@mail.gmail.com>

Thanks, Alex.

On Wed, May 28, 2008 at 10:13 AM, Alexey Verkhovsky <
averkhov at thoughtworks.com> wrote:

> > Does anyone have any feel for the requirements (disk space, memory,
> anything else you can think of) of a virtual machine (say Centos Linux),
> > set up as a CruiseControl.rb build machine?
>
> On a couple of CC.rb installations I oversee, long living dashboard
> processes tend to have RSS of about 40-50 Mb, and builder process are
> around 35-40 Mb. MRI never releases memory back to the OS, so those are the
> right numbers. Multiply by some safety factor and add whatever your build
> process itself uses. 256 or 512 Mb should be it.
>
> --Alex
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080528/44b7f4a4/attachment.html>

From jeremystellsmith at gmail.com  Wed May 28 12:29:25 2008
From: jeremystellsmith at gmail.com (Jeremy Stell-Smith)
Date: Wed, 28 May 2008 09:29:25 -0700
Subject: [Cruisecontrolrb-users] version 1.3 build log truncation
In-Reply-To: <OFF7BA5B16.72E87B0C-ON86257457.00586C15-86257457.00586C19@thoughtworks.com>
References: <OFF7BA5B16.72E87B0C-ON86257457.00586C15-86257457.00586C19@thoughtworks.com>
Message-ID: <b18eecea0805280929t4f9ac2b3u609561926b2d10fa@mail.gmail.com>

+1

On Wed, May 28, 2008 at 9:05 AM, Alexey Verkhovsky <
averkhov at thoughtworks.com> wrote:

> -----cruisecontrolrb-users-bounces at rubyforge.org wrote: -----
> >> Is the truncation in the build log file itself or just in the on-screen
> >> rendering?
> >Pretty sure it's just the web ui.  I believe you can even click the
> >link at the bottom of the build page to see the full log?
>
> It is just in the UI. Rationale for this was provided by a situation where
> several thousand tests were failing for the same reason, producing a huge
> log file, and the dashboard was running out of memory trying to parse it.
>
> The link at the bottom is not there yet, but surely is a good idea. I would
> actually put it inside the message that says that the file was too long. It
> would be even nicer if we displayed the first 100 Kb of the file, and had a
> "See more" link at the end, that would serve the whole thing as a text
> file, without parsing.
>
> Send patches! :)
>
> --Alex
>
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20080528/94eae25b/attachment.html>