I tried taking your changes but it failed with:
<Objs Version="1.1.0.1" 
xmlns="http://schemas.microsoft.com/powershell/2004/04";><S 
S="Error">C:\Users\ansible\AppData\Local\Temp\ansible-tmp-1414187414.25-97343749557638\de_x000D__x000A_</S><S
 
S="Error">ployLauncher.ps1 : A positional parameter cannot be found that 
accepts _x000D__x000A_</S><S S="Error">argument 
'False'._x000D__x000A_</S><S S="Error">At line:1 char:1_x000D__x000A_</S><S 
S="Error">+ &amp; _x000D__x000A_</S><S 
S="Error">C:\Users\ansible\AppData\Local\Temp\ansible-tmp-1414187414.25-97343749557638\\
 
_x000D__x000A_</S><S S="Error">..._x000D__x000A_</S><S S="Error">+ 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_x000D__x000A_</S><S
 
S="Error">~~~_x000D__x000A_</S><S S="Error"> + CategoryInfo : 
InvalidArgument: (:) [deployLauncher.ps1], Param _x000D__x000A_</S><S 
S="Error"> eterBindingException_x000D__x000A_</S><S S="Error"> + 
FullyQualifiedErrorId : 
PositionalParameterNotFound,deployLauncher.ps1_x000D__x000A_</S><S 
S="Error"> _x000D__x000A_</S></Objs>

Looking at the diff between your code and mine there's a few other 
differences. I'm running 1.7.2,  I assume your branched off something 
newer.I'll see if I can sort through the issue.

Thanks

On Friday, October 24, 2014 3:52:39 PM UTC-5, Michael Perzel wrote:
>
> Your idea with jinja filter is what I originally tried to get working. I 
> never managed it but I think its the ideal solution (converting yaml hash 
> to a powershell one). 
>
> If I follow your patch you added a parameter that controls whether or not 
> arguments get quoted (and set it to false for powershell scripts)? I'm not 
> particularly worried about nefarious activity within our system so this 
> could work for us.
>
> On Friday, October 24, 2014 12:52:52 AM UTC-5, Chris Church wrote:
>>
>> That method of passing arguments is apparently called "splatting" (
>> http://technet.microsoft.com/en-us/magazine/gg675931.aspx).
>>
>> I have a branch where I've been able to get it working:
>>
>> https://github.com/cchurch/ansible/tree/powershell_splatting
>>
>>
>> I've also added integration tests to show examples of it in use:
>>
>>
>> https://github.com/cchurch/ansible/blob/powershell_splatting/test/integration/roles/test_win_script/tasks/main.yml#L50
>>
>>
>> I also considered the idea of a Jinja2 filter to convert a YAML/JSON data 
>> structure to this format to allow for defining your arguments as you would 
>> any other variables:
>>
>> build_args:
>>
>>   key1: value1
>>
>>   key2: value2
>>
>>
>> You could then run your task as:
>>
>> script: dostuff.ps1 {{ build_args|splattify }}
>>
>>
>> Would you (or any other Windows users) be interested in this approach?
>>
>>
>> On Wed, Oct 22, 2014 at 10:28 AM, Michael Perzel <[email protected]> 
>> wrote:
>>
>>> I'll look into this. My work around thus far is using a template for my 
>>> deploy script. Instead of passing the deploy script arguments, I just 
>>> assign them at the top:
>>>
>>> $build = {{ build }}
>>> $pass = {{ password }}
>>> $arguments = @{ {{ arguments }} }
>>>
>>> This then becomes:
>>>
>>> $build = 42
>>> $pass = password
>>> $arguments = @{ key1=value1; key2= value2 }
>>>
>>> Using the template has given me complete control over the syntax. In our 
>>> paradigm we have an entirely generic "deploy" powershell script that stages 
>>> files, unzips them and similar things. It then calls an "install" script 
>>> that handles all the app specific items. The install scripts are bundled 
>>> with the specific app.
>>>
>>> On Wednesday, October 22, 2014 8:38:11 AM UTC-5, J Hawkesworth wrote:
>>>>
>>>> I don't have a direct answer for this - rightly or wrongly the ps1 
>>>>> scripts I have so far don't take any arguments - I consider them to be 
>>>>> specific to my roles and at the moment they embed some details that it 
>>>>> would probably be best to have as parameters.  However, it looks to me 
>>>>> like 
>>>>> your deployLauncher.ps1 really wants to be a very general purpose 
>>>>> deployment tool and maybe it would be better off as an ansible module.  
>>>>> That way you could perhaps take advantage of ansible's existing syntax 
>>>>> for 
>>>>> specifying module arguments.
>>>>>
>>>>
>>>> As an aside I believe @Trond Hindenes has a win_package module in the 
>>>> works which might do some of what you want.
>>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Ansible Project" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/ansible-project/388179f6-448e-44e7-967f-94e400dc4514%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/ansible-project/388179f6-448e-44e7-967f-94e400dc4514%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/ba6b122a-1fa5-48c6-9b1d-a8a2f67083ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to