This might not be a feature getting into Cap 2.4 , but definitely possibly the future:
having cap -T behave like rake -T , where you can enter in a task name and it will be filtered by the text you enter. I'll give 2.4.0 a whirl and see how it works. Jamis Buck wrote: > Capistrano 2.4.0 is almost ready. In fact, it _is_ ready, but there were > so many changes that I'm kind of afraid of putting a final stamp of > approval on it right out the gate. So instead, I'm releasing 2.4.0 > preview release #1 (real version 2.3.101). You can install it here: > > gem install --source http://gems.jamisbuck.org capistrano > > Here is the skinny on what's new and changed: > > > === death to "git fetch --tags" === > > You git users out there will be pleased to learn that this release will > no longer do "git fetch --tags", meaning your git-based deploys will > finally work again. Sorry that took so long to fix. It was really > ridiculously simple. :( > > > === cap -d === > > Mark Imbriaco added a debug switch for enabling conditional execution of > commands. This is fantastic for debugging and testing tasks, since you > can basically step through your tasks and approve or deny each remote > command as it is executed. Just give cap the "-d" switch to enable this. > > > === New and improved sudo helper === > > No, really. This time I mean it. I pulled the version of sudo introduced > in 2.3.0 (where each sudo command was wrapped in an explicit sh > invocation), and put it back almost exactly as it was. However, if you > call sudo without a command to execute, it will instead return the sudo > command to use. On top of that, if the run() helper detects that you're > using sudo, it will listen for password prompts. So you can now do > arbitrarily complex sudo commands like this: > > run "if [ -d /some/directory ]; then #{sudo} chmod -R g+w > /some/directory; fi" > > In other words, just dump the sudo() call into your command as an > interpolated value, and the real sudo command gets substituted. You can > pass options to it as well: > > run "#{sudo :as => "bob"} something" > > And, naturally, the original sudo() syntax we all know and love remains > as before: > > sudo "something", :as => "bob" > > The deployment recipes themselves have been updated to use this new > syntax, as needed. > > > === :runner vs. :admin_runner === > > Some cappers have noted that having deploy:setup and deploy:cleanup run > as the :runner user messed up their carefully crafted permissions. I > agreed that this was a problem. With this release, deploy:start, > deploy:stop, and deploy:restart all continue to use the :runner user > when sudoing, but deploy:setup and deploy:cleanup will use the > :admin_runner user. The :admin_runner variable is unset, by default, > meaning those tasks will sudo as root, but if you want them to run as > :runner, just do "set :admin_runner, runner". > > > === deploy:upload with globs === > > You can now specify glob patterns with deploy:upload: > > cap deploy:upload FILES="config/apache/*.conf" > > As before, you can also specify entire folders to upload, but now the > upload is being done via the upload() helper (introduced in 2.3.0) so > the behavior is more standardized. > > > === before/after hooks use well-defined server scope === > > Prior to this release, if you defined a before hook using a block, the > block would be executed within the same server scope as the original > task that invoked task that this hook was attached to. (whew!) > > In other words: > > task :first, :roles => :app do > # ... > second > end > > task :second, :roles => :db do > # ... > end > > before :second do > # ... > end > > Prior to this release, when "first" calls "second", the before hook at > the bottom would get called, but it would get called with the :roles => > :app server constraint active, instead of :roles => :db. This preview > release makes those hooks use the server scope of the task they are > attached to. > > > === host reported correctly from SCM output === > > Prior to this release, when any output was processed by the :checkout, > :export, or :remote_cache strategies, you'd not be able to tell what > host the output was from (it'd just be prefixed [err] or [out]). With > this release, that output is correctly tagged with the host that > generated it, making it easier to troubleshoot issues with SCM command > execution. > > > === Other lesser fixes, straight from the CHANGELOG === > > * Make git SCM honor the :scm_verbose option [Jamis Buck] > > * Don't follow symlinks when using :copy_cache [Jamis Buck] > > * If :mode is given to upload() helper, do a chmod after to set the mode > [Jamis Buck] > > * Fix load_from_file method for windows users [Neil Wilson] > > * Display a deprecation error if a remote git branch is specified [Tim > Harper] > > * Make set(:default_shell, false) work for not using a shell on a > per-command basis [Ryan McGeary] > > * Use upload() instead of put() with the copy strategy [Jamis Buck] > > * Improved test coverage [Ryan McGeary] > > * Fixed "coverage" take task [Ryan McGeary] > > * Fix deploy:pending when using git SCM [Ryan McGeary] > > * Make sure deploy:check works with :none scm (which has no default > command) [Jamis Buck] > > > > So, get out there and give this a spin. I'm tentatively going to release > 2.4.0 final later next week, unless anyone reports any major issues. > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
