tests: packaging
Directory with subdirectory "packaging" is called "component". List all components: python3 tests/packaging-doc.py --list Run all tests/compoments: python3 tests/packaging-doc.py Run specific test/component: python3 tests/packaging-doc.py --test <component> The file structure for 1 component: daemon - dependencies for 1 component "kresd daemon" (default component, must always be there) scripts/distros - dependencies for 1 component for specific distro (must always be there) scripts/dockerfile_gen.py - test Dockerfile generator, see below tests/packaging.py - script to generate and build all combinations of Docker files for all components [component] - directory of component/test, see below (e.g. "client/packaging/", "modules/http/packaging/" etc.) The file structure of each component: [component] <distro>/<version> - package names - builddeps - list of build depedencies - rundeps - list of runtime depedencies - pre-build.sh - script called before build phase - post-build.sh - script called after build phase - pre-run.sh - script called before run phase - post-run.sh - script called after run phase - install.sh and build.sh script called during build phase test.config or test.sh - kresd config test or shell script note: content of "scripts/distroos" is same as "<distro>/<version>" of component. There are "build" and "run" phases. "build" phase precedes "run" phase. All script are called in this order: 1. pre-<phase>.sh 2. install packages specifed in the file "<phase>deps" 3a. for "build" phase: run build.sh and install.sh 3b. for "run" phase: run 'kresd -c [component]/test.config' or config.sh 4. remove packages specified in the file "<phase>deps" 5. post-<phase>.sh Each step above is combines base components with a component under test. E.g. component "scripts/distros" always precedes component "daemon/packaging" and it precedes the tested component e.g. "modules/http". In long term we might migrate this to py.test or some other well known framework.