Test-remote-image - Revision history

Corneliu Stoicescu at 13:04, 15 July 2014

2014-07-15T13:04:33Z

← Older revision		Revision as of 13:04, 15 July 2014
Line 7:		Line 7:

	=Usage=		=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:		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)		# 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:		# 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:
Line 18:		Line 18:

	==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.

Line 31:		Line 31:
	=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 ~~already downloaded~~ ones. Because of this, please use the [[#Usage\|--skip-download]] option if needed.		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.

Corneliu Stoicescu at 12:58, 15 July 2014

2014-07-15T12:58:12Z

← Older revision		Revision as of 12:58, 15 July 2014
Line 27:		Line 27:
	=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 already downloaded ones. Because of this, please use the [[#Usage\|--skip-download]] option if needed.		At the moment of this writing, the PiblicAB repository profile does not identify if the already downloaded images are identical to the already downloaded ones. Because of this, please use the [[#Usage\|--skip-download]] option if needed.

Corneliu Stoicescu at 12:56, 15 July 2014

2014-07-15T12:56:23Z

Corneliu Stoicescu at 12:54, 15 July 2014

2014-07-15T12:54:52Z

← Older revision		Revision as of 12:54, 15 July 2014
Line 30:		Line 30:

	=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 already downloaded ones. Because of this, please use the [[#Usage\|--skip-download]] option if needed.

Corneliu Stoicescu at 12:49, 15 July 2014

2014-07-15T12:49:06Z

← Older revision		Revision as of 12:49, 15 July 2014
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		- fetches remote images required for testing
Line 6:		Line 6:
	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-script was meant to be easy and add as little extra configuration as possible. As a result, the required default steps are:		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:
	1) create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)		1) create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)
Line 13:		Line 13:
	--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.

	~~ADVANCED USAGE~~		=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 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 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=

Corneliu Stoicescu at 12:45, 15 July 2014

2014-07-15T12:45:41Z

← Older revision		Revision as of 12:45, 15 July 2014
Line 21:		Line 21:

	* Repository configuration		* Repository configuration
	Similarly to the target profiles, the script uses ~~repo~~ profiles for		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.
			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

Corneliu Stoicescu: Created page with "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 ..."

2014-07-15T12:36:40Z

Created page with "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 ..."

New page

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:
1) create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)
2) 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.

ADVANCED USAGE

* 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.
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 repo profiles for

← Older revision		Revision as of 12:56, 15 July 2014
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		* fetches remote images required for testing
	- runs the runtime tests using testimage and all its features		* 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.
Line 8:		Line 8:
	=Usage=		=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:		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:
	1) create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)		# create the build configuration just like creating the image locally and running the tests on it(but do not build the actual image)
	2) 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:		# 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=