1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
community.general/test
Feanil Patel 892e230514 Don't convert nulls to strings.
This change is similar to https://github.com/ansible/ansible/pull/10465

It extends the logic there to also support none types.  Right now if you have
a '!!null' in yaml, and that var gets passed around, it will get converted to
a string.

eg. defaults/main.yml
```
ENABLE_AWESOME_FEATURE: !!null # Yaml Null
OTHER_CONFIG:
  secret1: "so_secret"
  secret2: "even_more_secret"

CONFIG:
  hostname: "some_hostname"
  features:
    awesame_feature: "{{ ENABLE_AWESOME_FEATURE}}"
  secrets: "{{ OTHER_CONFIG }}"
```

If you output `CONFIG` to json or yaml, the feature flag would get represented in the output
as a string instead of as a null, but secrets would get represented as a dictionary.  This is
a mis-match in behaviour where some "types" are retained and others are not.  This change
should fix the issue.

I also updated the template test to test for this and made the changes to v2.

Added a changelog entry specifically for the change from empty string to null as the default.

Made the null representation configurable.

It still defaults to the python NoneType but can be overriden to be an emptystring by updating
the DEFAULT_NULL_REPRESENTATION config.
2015-08-19 18:35:07 -04:00
..
integration Don't convert nulls to strings. 2015-08-19 18:35:07 -04:00
units changed mod_args test to match connection 2015-08-19 00:34:37 -04:00
README.md Add mock and nose to requirements for running unit tests 2014-11-30 16:10:25 +01:00

Ansible Test System

Folders

unit

Unit tests that test small pieces of code not suited for the integration test layer, usually very API based, and should leverage mock interfaces rather than producing side effects.

Playbook engine code is better suited for integration tests.

Requirements: sudo pip install paramiko PyYAML jinja2 httplib2 passlib nose mock

integration

Integration test layer, constructed using playbooks.

Some tests may require cloud credentials, others will not, and destructive tests are separated from non-destructive so a subset can be run on development machines.

learn more

hop into a subdirectory and see the associated README.md for more info.