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