Cruisecontrolrb users - Aug 2008 - Keeping CRUISE_DATA_ROUTE under version control

I have a goal to allow any of us on the team to be able to fetch the  
build environment locally and run / hack it, them commit their  
changes back and be able to easily deploy them to the team''s shared  
build environment.

To that end, I''ve cloned the github repo for ccrb into a project in  
our private team repo, and then cloned that one onto my local machine.

I made a folder /data inside the cruisecontrol.rb folder, and  
configured CRUISE_DATA_ROOT to point to that folder.

I then added a couple of projects with cruise add.

I didn''t want the build history, or all the source for each project  
to be checked in with the build server code, so I excluded some files.

We use git, so I added a .gitignore folder in data/projects like this:
  work
  build-*
  builder.*
  builder_status.*

Now I''m trying to work out what I need to commit to the cruise git  
repo so that someone else could pull it and have all the projects.

I guess excluding the whole /work folder was a bit heavy handed,  
because you need at least some of what''s in work/.git in order for  
cruise to know where the project''s repository is... or is this stored  
anywhere else?

has anyone else tried to do this and succeeded?

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.



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

On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <matt at mattwynne.net>
wrote:
> I have a goal to allow any of us on the team to be able to fetch the build
> environment locally and run / hack it, them commit their changes back and
be
> able to easily deploy them to the team''s shared build environment.
Instead of moving where CRUISE_DATA_ROOT is, maybe you could just make
a script which symlinks/copies the files you need from your project to
the default location of ~/.cruise.

For example, have a ./setup_ccrb.rb scrpt in your project which will
clone the git repo, set up the project by issuing the correct .cruise
add command, and symlink site_config.rb/css.  You would have the same
symlinks in the shared environment.  All the symlinked files could
live in the project - and there shouldn''t be many more cruise-related
files to symlink than site_config and css, right?

-- Chad

the other file that you need is cruise_config.rb, this is a per project
config file.  in general, I''d suggest that it live inside the project
itself, because it''s much easier to configure that way.  however, you
can
also place it in <cruise>/<project_name>/ and in fact there should
be one
there that cruise creates for you.

why do you want to do what you''re suggesting?  I''m with chad,
I think it''d
be easier to create a script that recreates the cruise environment on a new
machine and uses files that you have checked into your project.  However, I
don''t know exactly what you''re trying to do, maybe you have a
good reason
for doing it the way you''re suggesting.

Jeremy

On Fri, Aug 29, 2008 at 8:13 AM, Chad Woolley <thewoolleyman at
gmail.com>wrote:
> On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <matt at mattwynne.net>
wrote:
> > I have a goal to allow any of us on the team to be able to fetch the
> build
> > environment locally and run / hack it, them commit their changes back
and
> be
> > able to easily deploy them to the team''s shared build
environment.
>
> Instead of moving where CRUISE_DATA_ROOT is, maybe you could just make
> a script which symlinks/copies the files you need from your project to
> the default location of ~/.cruise.
>
> For example, have a ./setup_ccrb.rb scrpt in your project which will
> clone the git repo, set up the project by issuing the correct .cruise
> add command, and symlink site_config.rb/css.  You would have the same
> symlinks in the shared environment.  All the symlinked files could
> live in the project - and there shouldn''t be many more
cruise-related
> files to symlink than site_config and css, right?
>
> -- Chad
> _______________________________________________
> 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/20080829/eb9b28c6/attachment.html>

On 29 Aug 2008, at 17:31, Jeremy Lightsmith wrote:
> the other file that you need is cruise_config.rb, this is a per  
> project config file.  in general, I''d suggest that it live inside
> the project itself, because it''s much easier to configure that  
> way.  however, you can also place it in
<cruise>/<project_name>/
> and in fact there should be one there that cruise creates for you.
>
> why do you want to do what you''re suggesting?  I''m with
chad, I
> think it''d be easier to create a script that recreates the cruise
> environment on a new machine and uses files that you have checked  
> into your project.  However, I don''t know exactly what
you''re
> trying to do, maybe you have a good reason for doing it the way  
> you''re suggesting.
>
> Jeremy
>
Well basically I would like to be able to check-in and thus re-create  
the whole of our build environment (= ccrb app from github + our  
custom hacks thereto + project config) very easily from source  
control. This is for two reasons:
	- if we lose our server for some reason, it''s trivial to recreate  
the build environment
	- people can easily clone the whole build environment and run it on  
their local dev machine, thereby reducing the friction of hacking and  
improving it

I''m used to CC.Net where we had all those horrible XML files in  
source control, which was about the one thing from those days that  
made any sense.

I take your and Chad''s point about just checking in a script with  
the ./cruise add commands in it - I think that''s what I''ll do
for now.

I guess some day it might be worth considering extending  
SourceControl.detect etc to read cruise_config.rb and see if there  
are any source control settings in there (in precedence to looking in  
the work folder for .git, .svn etc). This would allow you to check in  
the cruise_config.rb files and thus check in your source control config.

Does that make any more sense?

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.

> On Fri, Aug 29, 2008 at 8:13 AM, Chad Woolley  
> <thewoolleyman at gmail.com> wrote:
> On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <matt at mattwynne.net>  
> wrote:
> > I have a goal to allow any of us on the team to be able to fetch  
> the build
> > environment locally and run / hack it, them commit their changes  
> back and be
> > able to easily deploy them to the team''s shared build
environment.
>
> Instead of moving where CRUISE_DATA_ROOT is, maybe you could just make
> a script which symlinks/copies the files you need from your project to
> the default location of ~/.cruise.
>
> For example, have a ./setup_ccrb.rb scrpt in your project which will
> clone the git repo, set up the project by issuing the correct .cruise
> add command, and symlink site_config.rb/css.  You would have the same
> symlinks in the shared environment.  All the symlinked files could
> live in the project - and there shouldn''t be many more
cruise-related
> files to symlink than site_config and css, right?
>
> -- Chad
> _______________________________________________
> 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/20080829/af87d125/attachment-0001.html>

not sure if I understand right.  you currently can checkin your
cruise_config.rb file right into the root directory of your project.  this
file can have any source control settings you want.  the only problem is the
chicken and egg problem that you need the cruise_config.rb to read the
source control settings to download the project the first time.  but if you
put this into your script (that you check in), then I think you''re
golden.

On Fri, Aug 29, 2008 at 10:23 AM, Matt Wynne <matt at mattwynne.net>
wrote:
> On 29 Aug 2008, at 17:31, Jeremy Lightsmith wrote:
>
> the other file that you need is cruise_config.rb, this is a per project
> config file.  in general, I''d suggest that it live inside the
project
> itself, because it''s much easier to configure that way.  however,
you can
> also place it in <cruise>/<project_name>/ and in fact there
should be one
> there that cruise creates for you.
>
> why do you want to do what you''re suggesting?  I''m with
chad, I think it''d
> be easier to create a script that recreates the cruise environment on a new
> machine and uses files that you have checked into your project.  However, I
> don''t know exactly what you''re trying to do, maybe you
have a good reason
> for doing it the way you''re suggesting.
>
> Jeremy
>
>
> Well basically I would like to be able to check-in and thus re-create the
> whole of our build environment (= ccrb app from github + our custom hacks
> thereto + project config) very easily from source control. This is for two
> reasons: - if we lose our server for some reason, it''s trivial to
recreate
> the build environment
> - people can easily clone the whole build environment and run it on their
> local dev machine, thereby reducing the friction of hacking and improving
it
>
> I''m used to CC.Net where we had all those horrible XML files in
source
> control, which was about the one thing from those days that made any sense.
>
> I take your and Chad''s point about just checking in a script with
the
> ./cruise add commands in it - I think that''s what I''ll do
for now.
>
> I guess some day it might be worth considering extending
> SourceControl.detect etc to read cruise_config.rb and see if there are any
> source control settings in there (in precedence to looking in the work
> folder for .git, .svn etc). This would allow you to check in the
> cruise_config.rb files and thus check in your source control config.
>
> Does that make any more sense?
>
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> http://songkick.com
>
> In case you wondered: The opinions expressed in this email are my own and
> do not necessarily reflect the views of any former, current or future
> employers of mine.
>
>
> On Fri, Aug 29, 2008 at 8:13 AM, Chad Woolley <thewoolleyman at
gmail.com>wrote:
>
>> On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <matt at
mattwynne.net> wrote:
>> > I have a goal to allow any of us on the team to be able to fetch
the
>> build
>> > environment locally and run / hack it, them commit their changes
back
>> and be
>> > able to easily deploy them to the team''s shared build
environment.
>>
>> Instead of moving where CRUISE_DATA_ROOT is, maybe you could just make
>> a script which symlinks/copies the files you need from your project to
>> the default location of ~/.cruise.
>>
>> For example, have a ./setup_ccrb.rb scrpt in your project which will
>> clone the git repo, set up the project by issuing the correct .cruise
>> add command, and symlink site_config.rb/css.  You would have the same
>> symlinks in the shared environment.  All the symlinked files could
>> live in the project - and there shouldn''t be many more
cruise-related
>> files to symlink than site_config and css, right?
>>
>> -- Chad
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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/20080829/2412fc3c/attachment.html>

I guess what I want is for the chicken to come pre-packaged with  
enough information to be able to lay those eggs.

I.e. my build server comes configured with the instructions it needs  
to fetch the various projects from source control and start building  
them.

For example - for one rails project, I might want a build which runs  
every check-in and runs tests / specs, and another that runs nightly  
that runs selenium scripts etc. Pretty soon I''m going to end up with  
a bunch of hand-crafted stuff in /home/builder/.cruise on the build  
server which isn''t backed up anywhere.

I''m pretty new to linux, ruby and git, so there''s a lot of
stuff for
me to absorb right now. Perhaps in a few weeks I''ll be able to ask  
slightly more focussed questions!

On 29 Aug 2008, at 18:36, Jeremy Lightsmith wrote:
> not sure if I understand right.  you currently can checkin your  
> cruise_config.rb file right into the root directory of your  
> project.  this file can have any source control settings you want.   
> the only problem is the chicken and egg problem that you need the  
> cruise_config.rb to read the source control settings to download  
> the project the first time.  but if you put this into your script  
> (that you check in), then I think you''re golden.
>
> On Fri, Aug 29, 2008 at 10:23 AM, Matt Wynne <matt at mattwynne.net>
> wrote:
> On 29 Aug 2008, at 17:31, Jeremy Lightsmith wrote:
>
>> the other file that you need is cruise_config.rb, this is a per  
>> project config file.  in general, I''d suggest that it live
inside
>> the project itself, because it''s much easier to configure that
>> way.  however, you can also place it in
<cruise>/<project_name>/
>> and in fact there should be one there that cruise creates for you.
>>
>> why do you want to do what you''re suggesting?  I''m
with chad, I
>> think it''d be easier to create a script that recreates the
cruise
>> environment on a new machine and uses files that you have checked  
>> into your project.  However, I don''t know exactly what
you''re
>> trying to do, maybe you have a good reason for doing it the way  
>> you''re suggesting.
>>
>> Jeremy
>>
>
> Well basically I would like to be able to check-in and thus re- 
> create the whole of our build environment (= ccrb app from github +  
> our custom hacks thereto + project config) very easily from source  
> control. This is for two reasons:
> 	- if we lose our server for some reason, it''s trivial to recreate
> the build environment
> 	- people can easily clone the whole build environment and run it  
> on their local dev machine, thereby reducing the friction of  
> hacking and improving it
>
> I''m used to CC.Net where we had all those horrible XML files in  
> source control, which was about the one thing from those days that  
> made any sense.
>
> I take your and Chad''s point about just checking in a script with
> the ./cruise add commands in it - I think that''s what
I''ll do for now.
>
> I guess some day it might be worth considering extending  
> SourceControl.detect etc to read cruise_config.rb and see if there  
> are any source control settings in there (in precedence to looking  
> in the work folder for .git, .svn etc). This would allow you to  
> check in the cruise_config.rb files and thus check in your source  
> control config.
>
> Does that make any more sense?
>
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> http://songkick.com
>
> In case you wondered: The opinions expressed in this email are my  
> own and do not necessarily reflect the views of any former, current  
> or future employers of mine.
>
>
>> On Fri, Aug 29, 2008 at 8:13 AM, Chad Woolley  
>> <thewoolleyman at gmail.com> wrote:
>> On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <matt at
mattwynne.net>
>> wrote:
>> > I have a goal to allow any of us on the team to be able to fetch  
>> the build
>> > environment locally and run / hack it, them commit their changes  
>> back and be
>> > able to easily deploy them to the team''s shared build
environment.
>>
>> Instead of moving where CRUISE_DATA_ROOT is, maybe you could just  
>> make
>> a script which symlinks/copies the files you need from your  
>> project to
>> the default location of ~/.cruise.
>>
>> For example, have a ./setup_ccrb.rb scrpt in your project which will
>> clone the git repo, set up the project by issuing the correct .cruise
>> add command, and symlink site_config.rb/css.  You would have the same
>> symlinks in the shared environment.  All the symlinked files could
>> live in the project - and there shouldn''t be many more
cruise-related
>> files to symlink than site_config and css, right?
>>
>> -- Chad
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20080831/7694146a/attachment-0001.html>