That's because it affects parallelism and leads to spaghetti hell. It is highly inefficient to pull back the logic in parallel to a central machine and then get one chip to do all the checking in threads. Before to long you have a tool that starts to hit parallelism issues.
This sort of code needs to run on the target machine. What we need is a *remote* library of helper functions that is installed as a Gem on the remote machines. To be able to say to each machine 'make yourself ready to do X' is the essence of abstraction and encapsulation. The logic on the command station should do nothing more than check global settings and global files before deciding what the machines should do. Anything that is specific to a particular machine should be that machine's responsibility to sort out. I wonder whether Capistrano's abstractions are too simplistic to fully describe this type of logic separation. Perhaps what we really need is a mechanism to determine whether the task is a command task - executed on the command station - or a remote task where the logic is executed on the target machines. Perhaps in the context of the same variables hash. (It can't be that hard to upload the variables). NeilW On 14 Feb, 05:37, Mike Bailey <[EMAIL PROTECTED]> wrote: > Capistrano stops if it see's a non-zero return code. I'd like to be > able to perform conditional > actions on remote hosts by running tests on them and checking the > results from within > my deploy task. Something like: > > if run "uname -a | grep amd64" > deprec.update_user_crontab(:mongrel, "LD_PRELOAD=/usr/lib/jvm/ > java-1.5.0-sun-1.5.0.06/jre/lib/amd64/libzip.so") > end > > From hacking the code it seems to be really hard to get things back > from more than > just the first target server. This could be command output, return > codes or files. > > One answer is to move this conditional logic onto the servers in the > form or more > complex bash commands or ruby scripts. > > Another would be to extend Capistrano be able to run commands on > multiple machines > and do things with the output (pull back logfiles, tcpdumps, etc; get > output of commands > and do conditional login in the task or Capistrano functions). > > I'd really like to be able to have tasks check what distro is running > on the remote system > so that my tasks could use the appropriate capistrano plugins. > > Jamis, how much work do you think it would be to implement this? Can > you point to where > the hard bits would be? > > Is anyone else interested in (or had a crack at adding) this > functionality? > > - Mike --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
