On Wed, May 20, 2009 at 10:52 PM, Jeff Forcier <j...@bitprophet.org> wrote:
> Hi Jorge,
>
>> so I'm now thinking why not have some sort of whitelist of commands
>> that change no state on the server, this way we can have a dryrun
>> command to test a script without actually running anything.
>
> Right now, you can turn on debugging to see the exact command that
> will be run, if you're worried about string substitutions and shell
> escapes. Either pass --debug on the CLI, or wrap the code in question
> in a 'with show('debug'):' block. This will print out the "real"
> command in the "[hostname] run: foo bar" lines, e.g.::
>
> [hostname] run: /bin/bash -l -c "/path/to/command -f -l -a -g -s
> \"some quoted value\""
>
> Other than that, there's no existing "dry run" functionality, but I'd
> definitely be up for putting that in. You're correct that it's rather
> difficult to dry-run code that relies on output from the server, and
> there's really no way around that outside of mocking the remote calls
> to return some predefined value (which is what will need to be done
> for the unit testing).
>
> That wouldn't really work too well for dry-running user code, as your
> fabfile logic would still have to have extra logic to handle "non
> real" return values, in which case simply returning the empty string
> and dealing with that would be just as well, and a lot less work.
>
> At any rate, I think having run/sudo/etc being capable of skipping any
> actual network IO is still a good idea, and that's probably something
> I'd put in for 1.0 as I don't want to hold 0.9 up any longer (we need
> *something* stable ASAP!) I'll stick a note in the TODO.
>
I have been using the attached patch for a week without troubles, in
fact it's great to set the flag at the middle of a script to test
something out. really nice.
For now it skips the return option and to be honest I haven't need it yet.
PS: sorry I still don't know how to make a git branch, I got a github
article on my reading queue.
> Thanks,
> Jeff
>
commit a50c0c58a33337ee169e478188703114caea02e8
Author: Jorge Vargas <elpa...@elpargo-linux.(none)>
Date: Thu May 28 22:48:08 2009 -0400
- Adding a dryrun option
diff --git a/fabric/operations.py b/fabric/operations.py
index 7fb18f4..13afcfb 100644
--- a/fabric/operations.py
+++ b/fabric/operations.py
@@ -360,6 +360,10 @@ def run(command, shell=True):
print("[%s] run: %s" % (env.host_string, real_command))
elif output.running:
print("[%s] run: %s" % (env.host_string, command))
+
+ if env.dryrun:
+ return
+
channel = connections[env.host_string]._transport.open_session()
channel.exec_command(real_command)
capture = []
@@ -449,6 +453,10 @@ def sudo(command, shell=True, user=None, pty=False):
print("[%s] sudo: %s" % (env.host_string, real_command))
elif output.running:
print("[%s] sudo: %s" % (env.host_string, command))
+
+ if env.dryrun:
+ return
+
channel = connections[env.host_string]._transport.open_session()
# Create pty if necessary (using Paramiko default options, which as of
# 1.7.4 is vt100 $TERM @ 80x24 characters)
diff --git a/fabric/state.py b/fabric/state.py
index 822e3ae..24b2f9a 100644
--- a/fabric/state.py
+++ b/fabric/state.py
@@ -187,6 +187,21 @@ env_options = [
help="specify a new shell, defaults to '/bin/bash -l -c'"
),
+ # Debug output
+ # TODO: tie into global output controls better (this is just a stopgap)
+ make_option('--debug',
+ action='store_true',
+ default=False,
+ help="display debug output"
+ ),
+
+ make_option('--dryrun',
+ action='store_true',
+ default=False,
+ help="don't actually do anything"
+ ),
+
+
# Config file location
make_option('-c', '--config',
dest='rcfile',
_______________________________________________
Fab-user mailing list
Fab-user@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fab-user
