diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index c67468f143..0c1306d145 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -9161,18 +9161,17 @@
in your local.conf file.
Be sure to provide the IP address you need:
- TEST_EXPORT_ONLY = "1"
- TEST_TARGET = "simpleremote"
+ INHERIT +="testexport"
TEST_TARGET_IP = "192.168.7.2"
TEST_SERVER_IP = "192.168.7.1"
You can then export the tests with the following:
- $ bitbake core-image-sato -c testimage
+ $ bitbake core-image-sato -c testexport
Exporting the tests places them in the
Build Directory in
- tmp/testimage/core-image-sato, which
+ tmp/testexport/core-image-sato, which
is controlled by the
TEST_EXPORT_DIR variable.
@@ -9180,37 +9179,9 @@
You can now run the tests outside of the build environment:
- $ cd tmp/testimage/core-image-sato
+ $ cd tmp/testexport/core-image-sato
$ ./runexported.py testdata.json
-
- This "export" feature does not deploy or boot the target
- image.
- Your target (be it a Qemu or hardware one)
- has to already be up and running when you call
- runexported.py
-
-
-
-
- The exported data (i.e. testdata.json)
- contains paths to the Build Directory.
- Thus, the contents of the directory can be moved
- to another machine as long as you update some paths in the
- JSON.
- Usually, you only care about the
- ${DEPLOY_DIR}/rpm directory
- (assuming the RPM and Smart tests are enabled).
- Consequently, running the tests on other machine
- means that you have to move the contents and call
- runexported.py with
- "--deploy-dir path" as
- follows:
-
- ./runexported.py --deploy-dir /new/path/on/this/machine testdata.json
-
- runexported.py accepts other arguments
- as well as described using --help.
@@ -9385,6 +9356,78 @@
+
+
+ Installing Packages in the DUT Without the Package Manager
+
+
+ When a test requires a package built by BitBake, it is possible
+ to install that package.
+ Installing the package does not require a package manager be
+ installed in the device under test (DUT).
+ It does, however, require an SSH connection and the target must
+ be using the sshcontrol class.
+
+ This method uses scp to copy files
+ from the host to the target, which causes permissions and
+ special attributes to be lost.
+
+
+
+
+ A JSON file is used to define the packages needed by a test.
+ This file must be in the same path as the file used to define
+ the tests.
+ Furthermore, the filename must map directory to the test
+ module name with a .json extension.
+
+
+
+ The JSON file must include an object with the test name as
+ keys of an object or an array.
+ This object (or array of objects) uses the following data:
+
+ "pkg" - A mandatory string that is the
+ name of the package to be installed.
+
+ "rm" - An optional boolean, which defaults
+ to "false", that specifies to remove the package after
+ the test.
+
+ "extract" - An optional boolean, which
+ defaults to "false", that specifies if the package must
+ be extracted from the package format.
+ When set to "true", the package is not automatically
+ installed into the DUT.
+
+
+
+
+
+ Following is an example JSON file that handles test "foo"
+ installing package "bar" and test "foobar" installing
+ packages "foo" and "bar".
+ Once the test is complete, the packages are removed from the
+ DUT.
+
+ {
+ "": {
+ "pkg": "bar"
+ },
+ "foobar": [
+ {
+ "pkg": "foo",
+ "rm": true
+ },
+ {
+ "pkg": "bar",
+ "rm": true
+ }
+ ]
+ }
+
+
+