Hello,
After a chat with Richard and Stefan, I came up with an outline of how the
oe-selftest feature(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740 )
should look like. I made a summary of my proposal below. Please feel free to
add your thoughts!
There will be a new script introduced(similar to bitbake-selftest) that will
use python unit test to execute tests. Name has not been decided but it can be
"oe-selftest".
Running this script will not compromise poky in any way.
Initially, the script does not need any preparation in order to be run. If this
changes in the future, the user will be prompted upon execution with the
pre-required tasks.
Oe-selftest can be used together with the automated runtime tests if necessary.
The following types of tests are targeted for the initial implementation:
- testing the functionality of scripts in poky/scripts (such as:
bitbake-layers, yocto-bsp, yocto-kernel, yocto-layers)
- testing of the 'bitbake' command and its output (this includes output data
validation such as the sstate-cache/ and tmp/ directories)
In order to achieve the above, the script will need to:
- manipulate configuration files and variables
- issue commands in a certain order
- analyze command output
- analyze output files and directories
- manage shared resources such as sstate-cache
Oe-selftest will use Python Unit Testing as follows:
- we will use what has already been done with the 'unittest'
and 'oeqa' classes. This includes 'decorators' and methods like 'skipModules'.
- the tests configuration files will be similar to those of the
automated runtime tests.
- because we are using the same framework and structure, the
output will also be similar to that of the automated runtime tests
- the build environments used will be set up in the
setUpClass() or setUpModule() methods
* local.conf may be modified here to use shared
resources like sstate-cache and downloads directory with other build
environments
- the build environments used will be removed in the
tearDownClass() or tearDownModule() methods
* this ensures no residue is left over that we
are not aware of
- we will add a new class oeqa.oeSelfTest that contains the
following base methods:
1) A few methods to manipulate variables in poky in a standardized way:
- oeSelfTest.var_rewrite(filepath_relative_to_poky_location,
variable_name, new_variable_value)
* resets a variable to the specified value(may
be similar to how HOB does to local.conf and bblayers.conf)
- oeSelfTest.var_append(filepath_relative_to_poky_location,
variable_name, appended_variable_value)
* appends data to a variable
- oeSelfTest.var_remove(filepath_relative_to_poky_location,
variable_name, remove_variable_value)
* removes data from a variable
2) We need to be able to execute tasks in a multiple build directories
environment.
- oeSelfTest.execute(command, build_dir)
* this method executes the command 'command'
from 'build_dir'
* for each execution, the environment is
sourced (similar to autobuilder)
(if the build directory does not exist, the
command will fail. This needs to be taken care of in the setUpClass() method)
* it returns the exit code and the output of
the command
Additional information/notes:
- class and method naming and structure is not final and open for suggestions
- poky under git is required for the script to work; we will use git to reset
modified files to default.
- a policy needs to be set in place(after experience has been gained from using
the tool) for working with a shared sstate-cache directory and multiple build
environments at a time.
- coding style is very important in order to get a reasonable execution time.
At the moment this is not a priority though.
- no strategy has been put in place yet in order to deal with multiple poky
environments
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
