Cruisecontrolrb users - Mar 2007 - a WARNING about cruise task or user-specified build task for Rails

If (like me) you use ccrb to test a Rails app
	and (like me) you define your own :cruise task, because, for  
example, you use rspec rather than Test::Unit
		and (like me) you have the RAILS_ENV ||= ''production'' line
in
environment.rb (because, like me, you use crummy shared hosting)
			Your build will run in production mode, possibly screwing up your  
production database, like mine!

(Happily, my crummy shared hosting service has non-crummy database  
backups, so no lasting harm was done.)

This is hinted at in the README of the 1.0 release, but not in the  
docs which tell how to customize your build.

Cruise team, this should be mentioned prominently in that section of  
the docs.  I would like to submit a doc patch, but I''m not sure what  
work around I should advise.

Aside from all that :), great project!  Much easier to set up than  
it''s CC siblings.  I look forward to using it for a long time.

Jim

[My First Post]
I know some people on the developer''s mailing list had caught wind of
this, but I wanted to share with everybody my success in getting CC.rb to work
with a Linux compiler to build Windows installers (Nullsoft''s NSIS). 
Getting a Linux development environment setup for the build was tough -hooking
it into CC.rb was pretty easy.  A description of how I got there is here:
http://cho.hapgoods.com/wordpress/?p=138

On another note: I saw that version 1.0 had come out and I upgraded to it BUT I
had to guess at the procedure.  In the end, I grafted the ..../projects
directory from 0.5 under 1.0 and adjusted the config file names.  Then all
worked great.

Finally, congrats to the developers.  This is a great tool.

Chris Hapgood
Phone: +1 434 989 8584
Skype: chris.hapgood
Email: cch1 at hapgoods.com

-----Original Message-----
From: cruisecontrolrb-users-bounces at rubyforge.org
[mailto:cruisecontrolrb-users-bounces at rubyforge.org] On Behalf Of Jim Hughes
Sent: Saturday, March 17, 2007 17:23
To: cruisecontrolrb-users at rubyforge.org
Subject: [Cruisecontrolrb-users] a WARNING about cruise task oruser-specified
build task for Rails

If (like me) you use ccrb to test a Rails app
	and (like me) you define your own :cruise task, because, for  
example, you use rspec rather than Test::Unit
		and (like me) you have the RAILS_ENV ||= ''production'' line
in
environment.rb (because, like me, you use crummy shared hosting)
			Your build will run in production mode, possibly screwing up your  
production database, like mine!

(Happily, my crummy shared hosting service has non-crummy database  
backups, so no lasting harm was done.)

This is hinted at in the README of the 1.0 release, but not in the  
docs which tell how to customize your build.

Cruise team, this should be mentioned prominently in that section of  
the docs.  I would like to submit a doc patch, but I''m not sure what  
work around I should advise.

Aside from all that :), great project!  Much easier to set up than  
it''s CC siblings.  I look forward to using it for a long time.

Jim
_______________________________________________
Cruisecontrolrb-users mailing list
Cruisecontrolrb-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users

>       and (like me) you have the RAILS_ENV ||=
''production'' line in
> environment.rb (because, like me, you use crummy shared hosting)
>          Your build will run in production mode, possibly screwing up 
your 
> production database, like mine!
Ouch.
> Cruise team, this should be mentioned prominently in that section of 
> the docs.  I would like to submit a doc patch, but I''m not sure
what
> work around I should advise.
Sure, we can document this. In fact I just did it. However, I want to be a 
tad more proactive.

In version 1., RAILS_ENV is cleared before calling a custom Rake task or 
build command (this includes ''cruise'' task). Would it be
better if
RAILS_ENV was set to ''test''? If your build needs something
different,
you''d just have to change it early on in your build script.

Anyone has a strong opinion one way or another?

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20070318/c6f11729/attachment.html

On Mar 17, 2007, at 10:08 PM, Alexey Verkhovsky wrote:
> In version 1., RAILS_ENV is cleared before calling a custom Rake  
> task or build command (this includes ''cruise'' task).
Would it be
> better if
> RAILS_ENV was set to ''test''? If your build needs
something
> different, you''d just have to change it early on in your build
script.
>
> Anyone has a strong opinion one way or another?
I wouldn''t call it a "strong opinion", but maybe something
like:

Project.configure do |project|
   project.environment = [
     { ''RAILS_ENV'' => ''test'' },
     { ''SOME_OTHER'' => ''foo'' }
   ]
end

and it would set the environment up based on that?

Then before running the build CC.rb could just do

project.environemnt.each { |key,val| ENV[key] = val } if  
project.environemnt

just a thought.

Michael-

Ok, so let me just take off my a**hat for a second and revise that to  
be:

Project.configure do |project|
   project.environment = {
     ''RAILS_ENV'' => ''test'',
     ''SOME_OTHER'' => ''foo''
   }
end

On Mar 17, 2007, at 10:26 PM, Michael Moen wrote:
>
> On Mar 17, 2007, at 10:08 PM, Alexey Verkhovsky wrote:
>
>> In version 1., RAILS_ENV is cleared before calling a custom Rake  
>> task or build command (this includes ''cruise'' task).
Would it be
>> better if
>> RAILS_ENV was set to ''test''? If your build needs
something
>> different, you''d just have to change it early on in your build
>> script.
>>
>> Anyone has a strong opinion one way or another?
>
> I wouldn''t call it a "strong opinion", but maybe
something like:
>
> Project.configure do |project|
>   project.environment = [
>     { ''RAILS_ENV'' => ''test'' },
>     { ''SOME_OTHER'' => ''foo'' }
>   ]
> end
>
> and it would set the environment up based on that?
>
> Then before running the build CC.rb could just do
>
> project.environment.each { |key,val| ENV[key] = val } if  
> project.environemnt
>
> just a thought.
>
> Michael-
>
>

I''d vote for alex''s suggestion of defaulting RAILS_ENV to
test, and it''s
always overrideable if someone wants to explicitly do that

On 3/17/07, Michael Moen <mi-ccrb at underpantsgnome.com>
wrote:
>
> Ok, so let me just take off my a**hat for a second and revise that to
> be:
>
> Project.configure do |project|
>    project.environment = {
>      ''RAILS_ENV'' => ''test'',
>      ''SOME_OTHER'' => ''foo''
>    }
> end
>
> On Mar 17, 2007, at 10:26 PM, Michael Moen wrote:
>
> >
> > On Mar 17, 2007, at 10:08 PM, Alexey Verkhovsky wrote:
> >
> >> In version 1., RAILS_ENV is cleared before calling a custom Rake
> >> task or build command (this includes ''cruise''
task). Would it be
> >> better if
> >> RAILS_ENV was set to ''test''? If your build needs
something
> >> different, you''d just have to change it early on in your
build
> >> script.
> >>
> >> Anyone has a strong opinion one way or another?
> >
> > I wouldn''t call it a "strong opinion", but maybe
something like:
> >
> > Project.configure do |project|
> >   project.environment = [
> >     { ''RAILS_ENV'' => ''test'' },
> >     { ''SOME_OTHER'' => ''foo'' }
> >   ]
> > end
> >
> > and it would set the environment up based on that?
> >
> > Then before running the build CC.rb could just do
> >
> > project.environment.each { |key,val| ENV[key] = val } if
> > project.environemnt
> >
> > just a thought.
> >
> > Michael-
> >
> >
>
> _______________________________________________
> 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/20070318/e17668cc/attachment-0001.html

First, I''d like to thank Thoughtworks and the CC.rb team for putting  
this tool together. I''m writing because I''m having a problem
getting
CC.rb to run on a non local box. I have a machine I''d like to be the  
build/CI machine, and I''ve installed CC on it and my dev box.
I''ve set the environment to test, added the project with "cruise  
add", started the project with "cruise start". CC.rb  works fine
on
my dev box, but for some reason, even though I''ve set RAILS_ENV equal  
to test, whenever I start the dashboard with "cruise start", the  
build fails because RAILS_ENV is set to "development". I''ve
tried
using the syntax earlier in this thread, but it resulted in the error  
below. Is there another way to set RAILS_ENV? Thanks.

-- Mark

[root at evans cruisecontrolrb-1.0.0]# more projects/widget/work/ 
cruise_config.rb
Project.configure do |project|
   project.email_notifier.emails = ["mark at grandkru.com"]
   project.environment={''RAILS_ENV''=>
''test''}
end

[root at evans cruisecontrolrb-1.0.0]# ./cruise start
=> Booting Mongrel (use ''script/server webrick'' to force
WEBrick)
=> Rails application starting on http://0.0.0.0:3333
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3333
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no  
restart).
** Rails signals registered.  HUP => reload (without restart).  It  
might not work well.
** Mongrel available at 0.0.0.0:3333
** Use CTRL-C to stop.


Processing ProjectsController#index (for 10.0.0.132 at 2007-03-27  
16:41:13) [GET]
   Parameters: {"action"=>"index",
"controller"=>"projects"}
Rendering layoutfalsecontent_typetext/htmlactionindex within layouts/ 
default
Rendering projects/index
Completed in 0.14984 (6 reqs/sec) | Rendering: 0.07669 (51%) | 200 OK  
[http://evans.lan/]


Processing ProjectsController#index (for 10.0.0.132 at 2007-03-27  
16:41:18) [GET]
   Parameters: {"format"=>"js",
"action"=>"index",
"controller"=>"projects"}
Rendering projects/refresh_projects
Completed in 0.02378 (42 reqs/sec) | Rendering: 0.02146 (90%) | 200  
OK [http://evans.lan/projects.js]
[fatal] [2007-03-27 16:41:19] Failed to load the new project  
configuration. The builder will stop.
Failed to load the new project configuration. The builder will stop.
[fatal] Could not load project configuration: undefined method  
`environment='' for #<Project:0xb7b962f4> in
./script/../config/../
script/../config/../app/models/project.rb:95:in `method_missing''
Builder for project ''widget'' exited

Yeah, as of right now builders ignore RAILS_ENV set by their parent 
process.
The project.environment={''RAILS_ENV''=>
''test''} syntax was proposed, but
not implemented.

I presume you have defined either ''cruise'' or custom task for
your build.
To define RAILS_ENV, you need to put the ENV[''RAILS_ENV''] =
''test''
statement somewhere in your build. I''d try something like this
(untested):

task ''cruise'' => [''cruise_init'',
''db:test:purge'', ''db:migrate'',
''test'']

task ''cruise_init'' do
  ENV[''RAILS_ENV''] = ''test''
end

To other CC.rb developers: Hmm... let''s admit, this is a nasty gotcha, 
with a complicated workaround. 

I''m starting to think that we should eliminate any dependency on
RAILS_ENV
from CC.rb itself, and pass it as-is from the shell all the way to the 
build. If somebody needs different environments for different builds, they 
would still have to do something like the above, though.

Thoughts?

Alex






Mark Nyon <mark at grandkru.com> 
Sent by: cruisecontrolrb-users-bounces at rubyforge.org
03/27/2007 03:07 PM

To

cc

Subject
Re: [Cruisecontrolrb-users] a WARNING about cruise task or user-specified 
build task for Rails






First, I''d like to thank Thoughtworks and the CC.rb team for putting 
this tool together. I''m writing because I''m having a problem
getting
CC.rb to run on a non local box. I have a machine I''d like to be the 
build/CI machine, and I''ve installed CC on it and my dev box.
I''ve set the environment to test, added the project with "cruise 
add", started the project with "cruise start". CC.rb  works fine
on
my dev box, but for some reason, even though I''ve set RAILS_ENV equal 
to test, whenever I start the dashboard with "cruise start", the 
build fails because RAILS_ENV is set to "development". I''ve
tried
using the syntax earlier in this thread, but it resulted in the error 
below. Is there another way to set RAILS_ENV? Thanks.

-- Mark

[root at evans cruisecontrolrb-1.0.0]# more projects/widget/work/ 
cruise_config.rb
Project.configure do |project|
   project.email_notifier.emails = ["mark at grandkru.com"]
   project.environment={''RAILS_ENV''=>
''test''}
end

[root at evans cruisecontrolrb-1.0.0]# ./cruise start
=> Booting Mongrel (use ''script/server webrick'' to force
WEBrick)
=> Rails application starting on http://0.0.0.0:3333
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3333
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no 
restart).
** Rails signals registered.  HUP => reload (without restart).  It 
might not work well.
** Mongrel available at 0.0.0.0:3333
** Use CTRL-C to stop.


Processing ProjectsController#index (for 10.0.0.132 at 2007-03-27 
16:41:13) [GET]
   Parameters: {"action"=>"index",
"controller"=>"projects"}
Rendering layoutfalsecontent_typetext/htmlactionindex within layouts/ 
default
Rendering projects/index
Completed in 0.14984 (6 reqs/sec) | Rendering: 0.07669 (51%) | 200 OK 
[http://evans.lan/]


Processing ProjectsController#index (for 10.0.0.132 at 2007-03-27 
16:41:18) [GET]
   Parameters: {"format"=>"js",
"action"=>"index",
"controller"=>"projects"}
Rendering projects/refresh_projects
Completed in 0.02378 (42 reqs/sec) | Rendering: 0.02146 (90%) | 200 
OK [http://evans.lan/projects.js]
[fatal] [2007-03-27 16:41:19] Failed to load the new project 
configuration. The builder will stop.
Failed to load the new project configuration. The builder will stop.
[fatal] Could not load project configuration: undefined method 
`environment='' for #<Project:0xb7b962f4> in
./script/../config/../
script/../config/../app/models/project.rb:95:in `method_missing''
Builder for project ''widget'' exited
_______________________________________________
Cruisecontrolrb-users mailing list
Cruisecontrolrb-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20070327/80ffd0f5/attachment-0001.html

On 28/03/2007, at 12:00 PM, Alexey Verkhovsky wrote:
> I''m starting to think that we should eliminate any dependency on  
> RAILS_ENV from CC.rb itself, and pass it as-is from the shell all  
> the way to the build. If somebody needs different environments for  
> different builds, they would still have to do something like the  
> above, though.
I definitely agree that CC.rb''s env shouldn''t be affecting the
builders'' env.

I''ve just been defining the RAILS_ENV directly in the build command  
as below, and it''s working a treat. I didn''t see a need to use
the
rake integration.

Project.configure do |project|
   project.build_command = ''rake db:migrate RAILS_ENV=test &&
rake
RAILS_ENV=test''
end

-- tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20070328/366ff446/attachment.html

Setting that build command in the projects/widget/work/ 
cruise_config.rb worked! Thanks much, Tim.

-- Mark

On Mar 28, 2007, at 3:06 AM, Tim Lucas wrote:
> On 28/03/2007, at 12:00 PM, Alexey Verkhovsky wrote:
>
>> I''m starting to think that we should eliminate any dependency
on
>> RAILS_ENV from CC.rb itself, and pass it as-is from the shell all  
>> the way to the build. If somebody needs different environments for  
>> different builds, they would still have to do something like the  
>> above, though.
>
> I definitely agree that CC.rb''s env shouldn''t be
affecting the
> builders'' env.
>
> I''ve just been defining the RAILS_ENV directly in the build
command
> as below, and it''s working a treat. I didn''t see a need
to use the
> rake integration.
>
> Project.configure do |project|
>   project.build_command = ''rake db:migrate RAILS_ENV=test
&& rake
> RAILS_ENV=test''
> end
>
> -- 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/20070328/126f42b8/attachment.html

On 3/28/07, Tim Lucas <t.lucas at toolmantim.com>
wrote:
> I definitely agree that CC.rb''s env shouldn''t be
affecting the builders''
> env.
Me too.  It would seem reasonable for the builders'' env to default to
test.

My team already had an environments.rake file patterned after
http://errtheblog.com/post/33, so we used the approach that Alexey
mentioned, and didn''t really think twice about it.

task :cruise => [:test_env, "db:migrate", :environment,
"spec:html_report", "spec:coverage",
"test:coverage"]

-- 
Nick