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 <[email protected]>
>> 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].
>>> 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
>>>
>>> <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/7558772c-08ec-43a5-86d4-229c11f6afd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
