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. For more options, visit https://groups.google.com/d/optout.
