[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] dryrun?

From: Jeff Forcier
Subject: Re: [Fab-user] dryrun?
Date: Wed, 20 May 2009 22:52:52 -0400

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]