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 <[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]> wrote:
On Fri, Aug 29, 2008 at 7:25 AM, Matt Wynne <[EMAIL PROTECTED]>
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
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
_______________________________________________
Cruisecontrolrb-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
