The answer is in the second topic


*Ok - I made it work in rundeck 
importhttp://symfony.com/doc/current/components/yaml/yaml_format.html 
<http://symfony.com/doc/current/components/yaml/yaml_format.html>*
*"Mappings use a colon followed by a space (: ) to mark each key/value 
pair:"*

*So I did some nasty change, removing the space in the JSON - it does not 
look well, but it works:*

*-e  '{ "versions": { "myapp": "0.1.2"} }'-e  '{ "versions":{ 
"myapp":"0.1.2"} }'*

W dniu piątek, 18 grudnia 2015 12:52:38 UTC+1 użytkownik sirkubax napisał:
>
> Unfortunatelly, it does not work as stated here
> https://groups.google.com/forum/#!topic/ansible-project/AKpHsOod9Lo
>
> The value does not get overriden unless the extra_args is passed in a JSON 
> format
> And I can not pass JSON in a yaml file  (or I did not find a way for it 
> yet)
>
> Like this:
> -e 'versions.myapp="0.1.2"'
> not like that:
> -e  '{ "versions": { "myapp": "0.1.2"} }'
>
> Reason - while importing jobs into rundeck it does complain about
> ml files)
> Error: Failed request to load jobs: Jobs Document was invalid for format 
> yaml: mapping values are not allowed here
> -e  '{"versions"*:* {"promo
>                        ^
>
> W dniu czwartek, 17 grudnia 2015 19:25:10 UTC+1 użytkownik sirkubax 
> napisał:
>>
>> Thanks Josh.
>>
>> I'm using that in other part of my inventory.
>> I was looking for 'non_dict' variable since I had some issue passing json 
>> as extra-args in rundeck yaml job deffiniton.
>> Well
>> I gave it another try, and I did succede ;)
>> Great
>>
>> just to show the example
>>
>> - id: xxxxxxxxxxxxxxxxxxxxxx
>>   project: xxxxxxxxx
>>   loglevel: INFO
>>   sequence:
>>     keepgoing: false
>>     strategy: node-first
>>     commands:
>>     - exec: sudo su - ansible bash -c """export ANSIBLE_FORCE_COLOR=true; 
>> cd ~/ansible; source ~/ansible/environment.sh; ansible-playbook 
>> ~/ansible/etc/playbooks/playbook.yml  *-e 
>> '{"versions[appA]":"$RD_OPTION_APP"}'* """
>>       description: setting up the app
>> (...)
>>    options:
>>     app:
>>      value: '1.2.3.4'       #here as a default value comes the value from 
>> the template -> *"{{ versions[choosen_app] }}" *
>>      values:
>>       - other_options
>>       - some dynamic option
>>
>>
>>
>> W dniu czwartek, 17 grudnia 2015 16:55:53 UTC+1 użytkownik Josh Smift 
>> napisał:
>>>
>>> There's no such thing as "double mustaches" -- once you're inside a {{ 
>>> }} 
>>> block, you're parsing Jinja. 
>>>
>>> When I want to do something like this, I use a more complicated struct, 
>>> like 
>>>
>>>   versions: 
>>>     appA: "1.2.3.4" 
>>>     appB: "4.3.2.1" 
>>>
>>> and then you can say 
>>>
>>>   - set_fact: 
>>>       choosen_app: 'appA' 
>>>       choosen_app_version: "{{ versions[choosen_app] }}" 
>>>
>>> and that should work. 
>>>
>>>                                       -Josh ([email protected]) 
>>>
>>>
>>>
>>> This email is intended for the person(s) to whom it is addressed and may 
>>> contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized 
>>> use, distribution, copying, or disclosure by any person other than the 
>>> addressee(s) is strictly prohibited. If you have received this email in 
>>> error, please notify the sender immediately by return email and delete the 
>>> message and any attachments from your system. 
>>>
>>

-- 
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/dfee83b0-6805-4205-9ec4-ae3986cab689%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to