From 85cc735b05be109e6daa5403efa4122b8b6e79d2 Mon Sep 17 00:00:00 2001 From: Christian Poessinger Date: Sun, 18 Oct 2020 21:58:30 +0200 Subject: README: update folder structure and tests --- README.md | 56 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 36 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 896f28b3d..edc58712e 100644 --- a/README.md +++ b/README.md @@ -3,18 +3,26 @@ [![Coverage](https://sonarcloud.io/api/project_badges/measure?project=vyos%3Avyos-1x&metric=coverage)](https://sonarcloud.io/component_measures?id=vyos%3Avyos-1x&metric=coverage) [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x?ref=badge_shield) -VyOS 1.1.x had its codebase split into way too many submodules for no good reason, which made it hard -to navigate or write meaningful changelogs. As the code undergoes rewrite in the new style in VyOS 1.2.0+, -we consolidate the rewritten code in this package. +VyOS 1.1.x had its codebase split into way too many submodules for no good +reason, which made it hard to navigate or write meaningful changelogs. As the +code undergoes rewrite in the new style in VyOS 1.2.0+, we consolidate the +rewritten code in this package. -If you just want to build a VyOS image, the repository you want is [vyos-build](https://github.com/vyos/vyos-build). -If you also want to contribute to VyOS, read on. +If you just want to build a VyOS image, the repository you want is +[vyos-build](https://github.com/vyos/vyos-build). If you also want to contribute +to VyOS, read on. ## Package layout ``` +data # Jinja2 templates +debian # Our package build system interface-definitions # Configuration interface (i.e. conf mode command) definitions op-mode-definitions # Operational command definitions +python # Programming library for accessing the config frontend/backend +schema # XML schema definition for conf mode and op mode commands +scripts # Build-time scripts +smoketest # Python Unittests for the CLI and system src conf_mode/ # Configuration mode scripts op_mode/ # Operational mode scripts @@ -23,30 +31,33 @@ src helpers/ # Misc helpers migration-scripts # Migration scripts tests/ # Unit tests - -python/ # Python modules - -scripts/ # Build-time scripts -schema/ # XML schemas ``` ## Interface/command definitions -Raw node.def files for the old backend are no longer written by hand or generated by custom sciprts. -They are all now produced from a unified XML format that supports a strict subset of the old backend -features. In particular, it intentionally does not support embedded shell scripts, default values, -and value "types", instead delegating those tasks to external scripts. +Raw `node.def` files for the old backend are no longer written by hand or +generated by custom sciprts. They are all now produced from a unified XML format +that supports a strict subset of the old backend features. In particular, it +intentionally does not support embedded shell scripts, default values, and value +"types", instead delegating those tasks to external scripts. -Configuration interface definitions must conform to the schema found in schema/interface_definition.rng -and operational command definitions must conform to schema/op-mode-definition.rng -Schema checks are performed at build time, so a package with malformed interface definitions will not build. +Configuration interface definitions must conform to the schema found in +`schema/interface_definition.rng` and operational command definitions must +conform to `schema/op-mode-definition.rng`. Schema checks are performed at build +time, so a package with malformed interface definitions will not build. ## Configuration scripts The guidelines in a nutshell: -* Use separate functions for retrieving configuration data, validating it, and generating taret config -* Use a template processor when the format is more complex than just one line (jinja2 and pystache are acceptable options) +* Use separate functions for retrieving configuration data, validating it, and + generating taret config, see our + [documentation](https://docs.vyos.io/en/latest/contributing/development.html#python) + for the common structure +* Use the `get_config_dict()` API as much as possible when retrieving values from + the CLI +* Use a template processor when the format is more complex than just one line + (Jinja2 and pystache are acceptable options) ## Tests @@ -58,6 +69,11 @@ pipenv shell make test ``` +### Runtime (Smoketests) + +Runtime tests are executed by the CI system on a running VyOS instance inside +QEMU. The testcases can be found inside the smoketest subdirectory which will +be placed into the vyos-1x-smoketest package. ## License -[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x?ref=badge_large) \ No newline at end of file +[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fvyos%2Fvyos-1x?ref=badge_large) -- cgit v1.2.3