7 ms·

I do a lot of ansible which needs to run on multiple versions, and their yaml typing are not consistent - whenever I have a variable in a logic statement, I nea

• polski-g 1y ago
  Yep. I just want strict yaml: anything encased in quotes is a string, anything not is not a string (bool, int or float)
  • deleted 1y ago
    [deleted]
  • awestroke 1y ago
    Including keys?
• mdaniel 1y ago
  This is likely hair splitting, but you are far more likely getting bitten by the monster amount of variance in jinja2 versions/behaviors than by anything "yaml-y" For example, yaml does not care about this whatsoever - name: skip on Tuesdays when: ansible_date_time.weekday != "Tuesday" but different ansible versions are pretty yolo about whether one needs to additionally wrap those fields in jinja2 mustaches - name: skip on Tuesdays when: '{{ ansible_date_time.weekday != "Tuesday" }}' and another common bug is when the user tries to pass in a boolean via "-e" because those are coerced into string key-value pairs as in $ ansible -e not_today=true -m debug -a var=not_today all localhost | SUCCESS => { "not_today": "true" } but if one uses the jinja/python compatible flavor, it does the thing $ ansible -e not_today=True -m debug -a var=not_today all localhost | SUCCESS => { "not_today": true } It may be more work than you care for, since sprinkling rampant |bool likely doesn't actively hurt anything, but the |type_debug filter[1] can help if it's behaving mysteriously 1: https://docs.ansible.com/ansible/11/collections/ansible/builtin/type_debug_filter.html#ansible-collections-ansible-builtin-type-debug-filter https://docs.ansible.com/ansible/11/collections/ansible/buil...