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/CAH%2BKTJ4PaBhzxo2kdNtMvSsd-jeBKDbm-%2BOFZ-RBWakzbWqaFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
