Test-remote-image: Difference between revisions
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=Description= | =Description= | ||
Yocto already offers the possibility to test a locally built image by setting the right configuration in conf/local.conf but sometimes testing a remotely built image is required. Such cases include testing official images for validation. For this purpose we made a script that: | Yocto already offers the possibility to test a locally built image by setting the right configuration in conf/local.conf but sometimes testing a remotely built image is required. Such cases include testing official images for validation. For this purpose we made a script that: | ||
* fetches remote images required for testing | |||
* runs the runtime tests using testimage and all its features | |||
The script can be found in the poky/scripts directory that is available in the PATH environment variable after sourcing into a build directory/environment. | The script can be found in the poky/scripts directory that is available in the PATH environment variable after sourcing into a build directory/environment. | ||
=Usage= | =Usage= | ||
Using the test-remote-image | Using the test-remote-image script was meant to be easy and add as little extra configuration as possible. As a result, the required default steps are: | ||
# create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image) | |||
# instead of using bitbake to build the image or start the tests, use the script. It will require the user to supply some parameters, some of them being optional. Following are some of the options used and their meaning, the rest can be understood using the --help option: | |||
--image-types = a list of iamge types to be tested (ex: core-image-minmal core-image-sato) | --image-types = a list of iamge types to be tested (ex: core-image-minmal core-image-sato) | ||
--repo-link = link to the images repository | --repo-link = link to the images repository | ||
--required-packages = packages that should be built before testing. For example, the psplash and rpm packages are used for 'smart' testing. | --required-packages = packages that should be built before testing. For example, the psplash and rpm packages are used for 'smart' testing. | ||
--skip-download = if running the script multiple times using the same build configuration and images repository, you can skip the download part using this option once the images have already been downloaded. | --skip-download = if running the script multiple times using the same build configuration and images repository, you can skip the download part using this option once the images have already been downloaded. | ||
=Advanced use= | =Advanced use= | ||
==Target configuration== | ==Target configuration== | ||
The script is made to work with most target types(read: MACHINE) by interacting the Target Controller used to test that target. For this end we defined target profiles that tells the script what images it should fetch for a given target and an AutoTargetProfile was implemented to automate as much of this as possible. | The script is made to work with most target types(read: MACHINE) by interacting the Target Controller used to test that target. For this end we defined target profiles that tells the script what images and other files it should fetch for a given target and an AutoTargetProfile was implemented to automate as much of this as possible. | ||
If this profile does not work for a given target, a new target profile should be implemented and selected from the script command line using the --target-profile option. This target profile class should extend the BaseTargetProfile abstract class and make sure the abstract methods are implemented as described in the script comments. | If this profile does not work for a given target, a new target profile should be implemented and selected from the script command line using the --target-profile option. This target profile class should extend the BaseTargetProfile abstract class and make sure the abstract methods are implemented as described in the script comments. | ||
==Repository configuration== | ==Repository configuration== | ||
Similarly to the target profiles, the script uses repository profiles for interacting with the images repository. By default the PublicAB repository profile is used but this does not suit your needs you can change it using the script command line --repo-profile option and choose a custom/other available profile. | Similarly to the target profiles, the script uses repository profiles for interacting with the images repository. By default the PublicAB repository profile is used but if this does not suit your needs you can change it using the script command line --repo-profile option and choose a custom/other available profile. | ||
If you do choose to implement a new repository profile, the new class should extend the abstract BaseRepoProfile class and implement the abstract methods defined within following the instructions in the script comments. | If you do choose to implement a new repository profile, the new class should extend the abstract BaseRepoProfile class and implement the abstract methods defined within following the instructions in the script comments. | ||
=Example usage= | =Example usage= | ||
test-remote-image --image-types core-image-sato-sdk core-image-sato --repo-profile http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6.1/ --required-packages rpm psplash | test-remote-image --image-types core-image-sato-sdk core-image-sato --repo-profile http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6.1/ --required-packages rpm psplash | ||
=Known issues= | =Known issues= | ||
At the moment of this writing, the PiblicAB repository profile does not identify if the already downloaded images are identical to the | At the moment of this writing, the PiblicAB repository profile does not identify if the already downloaded images are identical to the upstream ones and by default it will always re-download them. Because of this, please use the [[#Usage|--skip-download]] option if needed. | ||
Latest revision as of 13:04, 15 July 2014
Description
Yocto already offers the possibility to test a locally built image by setting the right configuration in conf/local.conf but sometimes testing a remotely built image is required. Such cases include testing official images for validation. For this purpose we made a script that:
- fetches remote images required for testing
- runs the runtime tests using testimage and all its features
The script can be found in the poky/scripts directory that is available in the PATH environment variable after sourcing into a build directory/environment.
Usage
Using the test-remote-image script was meant to be easy and add as little extra configuration as possible. As a result, the required default steps are:
- create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)
- instead of using bitbake to build the image or start the tests, use the script. It will require the user to supply some parameters, some of them being optional. Following are some of the options used and their meaning, the rest can be understood using the --help option:
--image-types = a list of iamge types to be tested (ex: core-image-minmal core-image-sato) --repo-link = link to the images repository --required-packages = packages that should be built before testing. For example, the psplash and rpm packages are used for 'smart' testing. --skip-download = if running the script multiple times using the same build configuration and images repository, you can skip the download part using this option once the images have already been downloaded.
Advanced use
Target configuration
The script is made to work with most target types(read: MACHINE) by interacting the Target Controller used to test that target. For this end we defined target profiles that tells the script what images and other files it should fetch for a given target and an AutoTargetProfile was implemented to automate as much of this as possible. If this profile does not work for a given target, a new target profile should be implemented and selected from the script command line using the --target-profile option. This target profile class should extend the BaseTargetProfile abstract class and make sure the abstract methods are implemented as described in the script comments.
Repository configuration
Similarly to the target profiles, the script uses repository profiles for interacting with the images repository. By default the PublicAB repository profile is used but if this does not suit your needs you can change it using the script command line --repo-profile option and choose a custom/other available profile. If you do choose to implement a new repository profile, the new class should extend the abstract BaseRepoProfile class and implement the abstract methods defined within following the instructions in the script comments.
Example usage
test-remote-image --image-types core-image-sato-sdk core-image-sato --repo-profile http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6.1/ --required-packages rpm psplash
Known issues
At the moment of this writing, the PiblicAB repository profile does not identify if the already downloaded images are identical to the upstream ones and by default it will always re-download them. Because of this, please use the --skip-download option if needed.
