fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] dryrun?


From: Jorge Vargas
Subject: Re: [Fab-user] dryrun?
Date: Thu, 28 May 2009 22:53:05 -0400

On Wed, May 20, 2009 at 10:52 PM, Jeff Forcier <address@hidden> 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
>

Attachment: dryrun.patch
Description: Text Data


reply via email to

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