Change Details

**Summary** During the 1.4.3 development cycle we faced an issue with a backport that used internal references not available in the 1.4 branch triggering a Python exception when running `show pki`. The idea(s) are * Have Python helper generating a list of all available commands in op-mode, with PLACEHOLDER inserted for tagNodes. * Have Python helper generating a list of all available commands in cfg-mode, with PLACEHOLDER inserted for tagNodes. Maybe suitable for the new documentation system * Evaluate if we can do static code analysis of our op-mode python scripts (idea from @zsdc). If we can have static coverage identifying such issue - we can even bake this into our `Makefile` - There are VSCode plugins available for such stuff - but having it in the build script is even better **Use case** Once we have a list of all available commands in op-mode we can traverse the `show` tree and issue every single op-mode `show` command from the smoketests dynamically, checking if any of the commands will throw an exception. This will heavily increase test coverage of the op-mode tree which is yet not really tested using smoketests.

**Summary** During the 1.4.3 development cycle we faced an issue with a backport that used internal references not available in the 1.4 branch triggering a Python exception when running `show pki`. The idea(s) are * Have Python helper generating a list of all available commands in op-mode, with PLACEHOLDER inserted for tagNodes. * Have Python helper generating a list of all available commands in cfg-mode, with PLACEHOLDER inserted for tagNodes. Maybe suitable for the new documentation system * Evaluate if we can do static code analysis of our op-mode python scripts (idea from @zsdc). If we can have static coverage identifying such issue - we can even bake this into our `Makefile` - There are VSCode plugins available for such stuff - but having it in the build script is even better **Use case** Once we have a list of all available commands in op-mode we can traverse the `show` tree and issue every single op-mode `show` command from the smoketests dynamically, checking if any of the commands will throw an exception. This will heavily increase test coverage of the op-mode tree which is yet not really tested using smoketests. Maybe related: https://forum.vyos.io/t/configuration-schema/16733/2

**Summary** During the 1.4.3 development cycle we faced an issue with a backport that used internal references not available in the 1.4 branch triggering a Python exception when running `show pki`. The idea(s) are * Have Python helper generating a list of all available commands in op-mode, with PLACEHOLDER inserted for tagNodes. * Have Python helper generating a list of all available commands in cfg-mode, with PLACEHOLDER inserted for tagNodes. Maybe suitable for the new documentation system * Evaluate if we can do static code analysis of our op-mode python scripts (idea from @zsdc). If we can have static coverage identifying such issue - we can even bake this into our `Makefile` - There are VSCode plugins available for such stuff - but having it in the build script is even better **Use case** Once we have a list of all available commands in op-mode we can traverse the `show` tree and issue every single op-mode `show` command from the smoketests dynamically, checking if any of the commands will throw an exception. This will heavily increase test coverage of the op-mode tree which is yet not really tested using smoketests. Maybe related: https://forum.vyos.io/t/configuration-schema/16733/2