mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
7bd57acda4
Fixes #10779 Refactor some of the block device, mount point, and mtab/fstab facts collection for linux for better performance on systems with lots of block devices. Instead of invoking 'lsblk' for every entry in mtab, invoke it once, then map the results to mtab entries. Change the args used for invoking 'findmnt' since the previous combination of args conflicts, so this would always fail on some systems depending on version. Add test cases for facts Hardware()/Network()/Virtual() classes __new__ method and verify they create the proper subclass based on the platform.system() results. Split out all the 'invoke some command and grab it's output' bits related to linux mount paths into their own methods so it is easier to mock them in unit tests. Fix the DragonFly* classes that did not defined a 'platform' class attribute. This caused FreeBSD systems to potentially get the DragonFly* subclasses incorrectly. In practice it didnt matter much since the DragonFly* subclasses duplicated the FreeBSD ones. Actual DragonFly systems would end up with the generic Hardware() etc instead of the DragonFly* classes. Fix Hardware.__new__() on PY3, passing args to __new__ would cause "object() takes no parameters" errors. So check for PY3 and just call __new__ without the args See https://hg.python.org/cpython/file/44ed0cd3dc6d/Objects/typeobject.c#l2818 for some explaination. |
||
|---|---|---|
| .. | ||
| code-smell | ||
| integration | ||
| samples | ||
| units | ||
| utils | ||
| README.md | ||
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.