Alright, I made your changes in your 1.7.2 branch and it works if the
variables are defined with quotes in the following order (I updated the
gist to reflect this).
vars:
installArguments: "@{key='value'}"
although it echo's the hash value correctly (it is just "value" maybe not
the best naming) it returns something in stderr. At this point I have no
clue what it means but I'm searching the google.
TASK: [debug var=deploy]
******************************************************
ok: [mdm-wsrv99.surescripts-dev.qa] => {
"deploy": {
"changed": true,
"invocation": {
"module_args": "deploy.ps1 -installArguments
\"@{key='value'}\"",
"module_name": "script"
},
"rc": 0,
"stderr": "#< CLIXML\r\n<Objs Version=\"1.1.0.1\"
xmlns=\"http://schemas.microsoft.com/powershell/2004/04\";><Obj
S=\"progress\" RefId=\"0\"><TN
RefId=\"0\"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64
N=\"SourceId\">1</I64><PR N=\"Record\"><AV>Preparing modules for first
use.</AV><AI>0</AI><Nil
/><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD>
</SD></PR></MS></Obj></Objs>",
"stdout": "Install Arguments: value\n",
"stdout_lines": [
"Install Arguments: value"
]
}
}
ok: [mdm-wsrv98.surescripts-dev.qa] => {
"deploy": {
"changed": true,
"invocation": {
"module_args": "deploy.ps1 -installArguments
\"@{key='value'}\"",
"module_name": "script"
},
"rc": 0,
"stderr": "#< CLIXML\r\n<Objs Version=\"1.1.0.1\"
xmlns=\"http://schemas.microsoft.com/powershell/2004/04\";><Obj
S=\"progress\" RefId=\"0\"><TN
RefId=\"0\"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64
N=\"SourceId\">1</I64><PR N=\"Record\"><AV>Preparing modules for first
use.</AV><AI>0</AI><Nil
/><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD>
</SD></PR></MS></Obj></Objs>",
"stdout": "Install Arguments: value\n",
"stdout_lines": [
"Install Arguments: value"
]
}
}
On Saturday, October 25, 2014 3:30:44 PM UTC-5, Michael Perzel wrote:
>
> 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 <michae...@gmail.com>
>> 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 <michae...@gmail.com>
>>>>> 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 ansible-proje...@googlegroups.com.
>>>>>> To post to this group, send email to ansible...@googlegroups.com.
>>>>>> 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 ansible-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>> 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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/7558772c-08ec-43a5-86d4-229c11f6afd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
