Take a look at this
gist: https://gist.github.com/perzizzle/b3e13af9e94d9fbb7970/download
It contains a simple playbook that calls a deploy.ps1 that should echo back
installArguments (which is a powershell array). I tried a few different
ways of quoting it with your patch applied but I get argument
transformation errors. Next I'll trying doing a git pull on your entire
branch, so far I had just been modifying the files you edited. I tested
calling deploy.ps1 from a windows server and it does work if provided valid
powershell syntax.
.\deploy.ps1 -installArguments @{key="value"}
I'll take a look at your tests and make sure I'm not doing anything
different.
On Saturday, October 25, 2014 2:23:55 PM UTC-5, Chris Church wrote:
>
> Could you create a gist (https://gist.github.com/) with the relevant
> lines from your inventory variables, playbook and script (removing any
> sensitive information)? I'm not quite able to piece together a full
> example of what you're running from the email thread.
>
> My branch is based on devel; I just created another branch based on 1.7.2
> with the splatting changes applied:
> https://github.com/cchurch/ansible/tree/powershell_splatting_v172
>
>
>
>
> On Fri, Oct 24, 2014 at 6:12 PM, Michael Perzel <[email protected]
> <javascript:>> wrote:
>
>> 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">+ & _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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/ba6b122a-1fa5-48c6-9b1d-a8a2f67083ef%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/ba6b122a-1fa5-48c6-9b1d-a8a2f67083ef%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/be52b260-220e-4d80-95d2-1210eb9e9adf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
