Re: [Fab-user] dryrun?

[Jorge Vargas]

On Fri, May 29, 2009 at 4:09 AM, Christian Vest
Hansen<address@hidden> wrote:
> On Fri, May 29, 2009 at 4:53 AM, Jorge Vargas <address@hidden> wrote:
>> 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.
>
> That part is easy. Get a github account (a free one will do), go to
> bitprophet/fabric, press "fork" and then git-clone, modify and push
> changes to your fork.
>
I'm still struggling with two balls (my local commits, and pulling
from master) don't add a third ball just yet :)

So do you think dryrun can go in?

>>
>>> Thanks,
>>> Jeff
>>>
>>
>> _______________________________________________
>> Fab-user mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/fab-user
>>
>>
>
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>