Cruisecontrolrb users - Jan 2008 - Builder Plugin vs. Rails Plugin vs. ??? for one-click deploy

This morning I sat down to try to start writing a cruise plugin that
allows you to deploy (''cap deploy'' or something similar) a
revision
that has built successfully by clicking a link or button on the
builds/show page.  (I.e., something that satisfies
http://jira.public.thoughtworks.org/browse/CCRB-55.)

Since I want to be able to configure the command to run in each
project''s cruise_config.rb, I looked into making it a builder plugin
(even though those normally do all their work in the builder processes
rather than the web app).  I was happy to find the builder plugins are
created in the web app process, but then disappointed to find out the
project configuration isn''t loaded in that process, only in the
builders.

Is there a recommended approach for this sort of thing?

Thanks.
-hume.

On Jan 5, 2008 12:42 PM, John D. Hume <duelin.markers at gmail.com>
wrote:
> This morning I sat down to try to start writing a cruise plugin that
> allows you to deploy (''cap deploy'' or something similar)
a revision
> that has built successfully by clicking a link or button on the
> builds/show page.  (I.e., something that satisfies
> http://jira.public.thoughtworks.org/browse/CCRB-55.)
>
> Since I want to be able to configure the command to run in each
> project''s cruise_config.rb, I looked into making it a builder
plugin
> (even though those normally do all their work in the builder processes
> rather than the web app).  I was happy to find the builder plugins are
> created in the web app process, but then disappointed to find out the
> project configuration isn''t loaded in that process, only in the
> builders.
This seems to make sense, only the builders should know about their
projects.  Maybe you can define a generic message (:deploy) that
triggers a build process to do something, similar to the build now
button.  The builder process could then figure out how to
''deploy'',
based on the individual project config (or do nothing, or do a default
command, if it is not configured).

Kind of vague, sorry, I didn''t review the source.  Would that work?

Chad Woolley wrote:
> This seems to make sense, only the builders should know about their
> projects.
I assume you mean their plugins.  Yeah, that makes sense; I was just
surprised to see that the web app process has instances of all the
builder plugins, but without their configuration loaded.  It seems
like if they''re going to be there they ought to be configured.  (Maybe
the plugin instances are there as a side-effect of the plugin_loader
code sitting at the bottom of project.rb?)
> Maybe you can define a generic message (:deploy) that
> triggers a build process to do something, similar to the build now
> button.  The builder process could then figure out how to
''deploy'',
> based on the individual project config (or do nothing, or do a default
> command, if it is not configured).
It''s an option (with some really nasty monkey-patching to
PollingScheduler), but it seems like a bad thing to give the builder
process a second job.  The deploy doesn''t really belong in the web app
process (in case it''s long-running) but doesn''t belong in the
builder
either.

I think I''ll dispense with configuring the deploy via cruise_config.rb
and just make a normal Rails plugin for the time being.

Thanks.
-hume.

On Jan 7, 2008 10:17 PM, John D. Hume <duelin.markers at gmail.com>
wrote:
> Chad Woolley wrote:
> I think I''ll dispense with configuring the deploy via
cruise_config.rb
> and just make a normal Rails plugin for the time being.
What we do is make a tag for all green builds, and create that as a
build artifact file (named after the tag and containing the tag).  We
then manually deploy that tag with capistrano via copy and paste.  It
works, and we have to type in the server pw anyway, so it has to be
manual.