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