namespaces especially ones you create yourself are usually not defined
with a default task. Deploy however does and that begins the magic
chain of events.
If you want to trigger a deploy from another task call
'deploy.default'; but before you rush to do that with your stage tasks
it will prevent you from doing anything other than a deploy with your
stage which is bad; I always prefer to have the stage decoupled from
what I want to do with that stage.
task :top_level_task_that_calls_a_deploy do
logger.info "Luke, I'm your father..."
deploy.default
end
$ cap top_level_task_that_calls_a_deploy
* executing `top_level_task_that_calls_a_deploy'
** Luke, I'm your father...
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
...
namespace :namespace_with_a_default_task do
task :default do
logger.info "Y U CALL ME?"
end
end
$ cap namespace_with_a_default_task
* executing `namespace_with_a_default_task'
** Y U CALL ME?
On Nov 9, 2011, at 9:07 AM, Craig White <craig.wh...@ttiltd.com> wrote:
>
> On Nov 9, 2011, at 8:53 AM, Lee Hambley wrote:
>
>> Then you have two independent projects, not two stages.
>>
>> I recommend using git submodules, still - and tracking your i18n separately,
>> and when you need to "deploy" your translations, make a one-liner task go to
>> the app, and do a `git submodule update`. Then Git (a content tracker) will
>> track when your translations were last deployed (or rather, what version was
>> last deployed, which I'd wager is just as important.)
>>
>> And your developers won't have to care about checking out and symlinking,
>> and keeping up to date two trees, and your deployments will always be a
>> one-shot, with an option to deploy translations when they become available
>> without requiring an extensive re-deploy of the whole I18n tree, and
>> re-symlinking into the project root.
>>
>> I guess my point is "use your tools" - symlinking/etc on the filesystem and
>> deploying two separate stacks, and symlinking codebases with
>> interdependencies is going to be horribly unreliable, and violates the
>> principle of least surprise (submodules were designed to solve this problem
>> (dependent projects with alternate release cycles)) so why not leverage them
>> to your advantage?
>>
>> Sounds like you're resisting a bit, because you are already invested in this
>> route, which I fear may be a mistake for you.
> ----
> I get the impression that 'namespace :deploy' has a magic to itself that will
> perform the subversion checkout magic that I can't seem to make happen in any
> other namespace.
>
> Craig
>
> --
> * You received this message because you are subscribed to the Google Groups
> "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> * To unsubscribe from this group, send email to
> capistrano+unsubscr...@googlegroups.com For more options, visit this group at
> http://groups.google.com/group/capistrano?hl=en
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to capistrano@googlegroups.com
* To unsubscribe from this group, send email to
capistrano+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
