Hello Lee-
Thanks for your response.
My hesitance to duplicate the :copy strategy is because I'd be
duplicating a non-trivial bit of code (53 lines of the deploy! method)
to hook into one spot that's already doing a "modify the checked out
directory before copying it" to make it do just one more thing. Newer
versions of capistrano might have extra features or bug fixes that I'd
need to keep up with, {blah blah, fragile code blah DRY blah}.
I guess I was trying to provoke a little conversation about how
capistrano itself could make this easy, with some sort of hooking
mechanism. It'd also be useful to do things just before copying from
the SCM working directory to the deployment staging area. There are
probably other places where standard strategies could be made a lot
more useable with a little more hookability.
(Tactically I will probably wind up doing the monkey patching ...
looked at the other way it *is* only 53 lines of code ;-)
Regards,
-Bill
On Oct 30, 2008, at 4:31 PM, Lee Hambley wrote:
> Bill,
>
> There's no reason you can't take the :copy strategy, and alter it to
> suit your needs, and put it in your own file (share it with the
> world.. maybe?) that you load in your Capfile...
>
> Without having the time to really understand where you're going with
> this, that seems like the logical idea.. and thats' how you'd be
> expected to overload complex tasks/namespaces.
>
> It's worth a note that the before_<task> and after_<task> methods,
> since Capistrano 2.x are [informally?] deprecated, and replaced with
> before() and after() helpers that take either "task" or
> "namespace:task" style stringified arguments (search the list, I
> wrote a comprehensive reply to a question about those just a couple
> of days ago).
>
> -- erm, lost my train of thought... hope I helped - a little - come
> back if you need more clarification?
>
> Lee Hambley
>
> 2008/10/30 Bill Kirtley <[EMAIL PROTECTED]>
>
> Hello-
>
> We've got a topology that seems well suited to using the copy
> strategy:
> 1 - 'svn up -r {xyz}' to a local cache directory
> 2 - copy_exclude to another local directory
> 3 - execute local transforms on the local staging directory
> 4 - compress that directory to a single .zip file
> 5 - copy that zip file to the remote servers
> 6 - unpack it there into releases_path
>
> The copy strategy does this exactly, and comes tantalizingly close to
> what I need. My problem is that I want to do more in step 3.
>
> The current copy strategy step 3 writes a REVISION file reflecting
> what revision was checked out.
>
> I want to do some more processing that is:
> a) Post checkout (not in our SCM repo)
> b) Run on the capistrano console and not on the app servers
> c) Results in a package that's copied identically to all servers.
>
> I could monkey-patch the Capistrano::Deploy::Strategy::Copy#deploy!
> function, and paste my code smack in the middle. This solution works
> OK but feels fragile, obscure, WRONG.
>
> What's the best practice here? The pattern of having before_{task}
> and after_{task} tasks feels tidy, but it's hard to see how to
> introduce it here.
>
> Am I stuck writing my own strategy that derives from Copy? Or monkey
> patching Copy itself?
>
> Thanks,
> -Bill Kirtley
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
