diff options
Diffstat (limited to 'scripts/patchtest.README')
-rw-r--r-- | scripts/patchtest.README | 62 |
1 files changed, 34 insertions, 28 deletions
diff --git a/scripts/patchtest.README b/scripts/patchtest.README index 76b5fcdb6d..3c1ee1af1d 100644 --- a/scripts/patchtest.README +++ b/scripts/patchtest.README | |||
@@ -3,40 +3,35 @@ | |||
3 | ## Introduction | 3 | ## Introduction |
4 | 4 | ||
5 | Patchtest is a test framework for community patches based on the standard | 5 | Patchtest is a test framework for community patches based on the standard |
6 | unittest python module. As input, it needs tree elements to work properly: | 6 | unittest python module. As input, it needs three elements to work properly: |
7 | a patch in mbox format (either created with `git format-patch` or fetched | 7 | |
8 | from 'patchwork'), a test suite and a target repository. | 8 | - a patch in mbox format (either created with `git format-patch` or fetched |
9 | from 'patchwork') | ||
10 | - a test suite | ||
11 | - a target repository | ||
9 | 12 | ||
10 | The first test suite intended to be used with patchtest is found in the | 13 | The first test suite intended to be used with patchtest is found in the |
11 | openembedded-core repository [1] targeted for patches that get into the | 14 | openembedded-core repository [1], targeted for patches that get into the |
12 | openembedded-core mailing list [2]. This suite is also intended as a | 15 | openembedded-core mailing list [2]. This suite is also intended as a |
13 | baseline for development of similar suites for other layers as needed. | 16 | baseline for development of similar suites for other layers as needed. |
14 | 17 | ||
15 | Patchtest can either run on a host or a guest machine, depending on which | 18 | Patchtest can either run on a host or a guest machine, depending on |
16 | environment the execution needs to be done. If you plan to test your own patches | 19 | which environment you prefer. If you plan to test your own patches (a |
17 | (a good practice before these are sent to the mailing list), the easiest way is | 20 | good practice before these are sent to the mailing list), the easiest |
18 | to install and execute on your local host; in the other hand, if automatic | 21 | way is to install and execute on your local host; in the other hand, if |
19 | testing is intended, the guest method is strongly recommended. The guest | 22 | automatic testing is intended, the guest method is strongly recommended. |
20 | method requires the use of the patchtest layer, in addition to the tools | 23 | The guest method requires the use of the patchtest layer, in addition to |
21 | available in oe-core: https://git.yoctoproject.org/patchtest/ | 24 | the tools available in oe-core: https://git.yoctoproject.org/patchtest/ |
22 | 25 | ||
23 | ## Installation | 26 | ## Installation |
24 | 27 | ||
25 | As a tool for use with the Yocto Project, the [quick start guide](https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html) | 28 | As a tool for use with the Yocto Project, the [quick start |
26 | contains the necessary prerequisites for a basic project. In addition, | 29 | guide](https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html) |
27 | patchtest relies on the following Python modules: | 30 | contains the necessary prerequisites. In addition, patchtest relies on |
28 | 31 | several Python modules for parsing and analysis, which can be installed | |
29 | - boto3 (for sending automated results emails only) | 32 | by running `pip install -r meta/lib/patchtest/requirements.txt`. Note |
30 | - git-pw>=2.5.0 | 33 | that git-pw is not automatically added to the user's PATH; by default, |
31 | - jinja2 | 34 | it is installed at ~/.local/bin/git-pw. |
32 | - pylint | ||
33 | - pyparsing>=3.0.9 | ||
34 | - unidiff | ||
35 | |||
36 | These can be installed by running `pip install -r | ||
37 | meta/lib/patchtest/requirements.txt`. Note that git-pw is not | ||
38 | automatically added to the user's PATH; by default, it is installed at | ||
39 | ~/.local/bin/git-pw. | ||
40 | 35 | ||
41 | For git-pw (and therefore scripts such as patchtest-get--series) to work, you need | 36 | For git-pw (and therefore scripts such as patchtest-get--series) to work, you need |
42 | to provide a Patchwork instance in your user's .gitconfig, like so (the project | 37 | to provide a Patchwork instance in your user's .gitconfig, like so (the project |
@@ -74,7 +69,7 @@ the target project, but these parameters can be configured using the `--limit`, | |||
74 | To run patchtest on the host, do the following: | 69 | To run patchtest on the host, do the following: |
75 | 70 | ||
76 | 1. In openembedded-core/poky, do `source oe-init-build-env` | 71 | 1. In openembedded-core/poky, do `source oe-init-build-env` |
77 | 2. Generate patch files from the target repository by doing `git-format patch -N`, | 72 | 2. Generate patch files from the target repository by doing `git format-patch -N`, |
78 | where N is the number of patches starting at HEAD, or by using git-pw | 73 | where N is the number of patches starting at HEAD, or by using git-pw |
79 | or patchtest-get-series | 74 | or patchtest-get-series |
80 | 3. Run patchtest on a patch file by doing the following: | 75 | 3. Run patchtest on a patch file by doing the following: |
@@ -123,7 +118,7 @@ The general flow of guest mode is: | |||
123 | -device virtio-9p-pci,fsdev=test_mount,mount_tag=test_mount -smp 4 -m | 118 | -device virtio-9p-pci,fsdev=test_mount,mount_tag=test_mount -smp 4 -m |
124 | 2048"` | 119 | 2048"` |
125 | 120 | ||
126 | Patchtest runs as an initscript for the core-image-patchtest image and | 121 | Patchtest is run by an initscript for the core-image-patchtest image and |
127 | shuts down after completion, so there is no input required from a user | 122 | shuts down after completion, so there is no input required from a user |
128 | during operation. Unlike in host mode, the guest is designed to | 123 | during operation. Unlike in host mode, the guest is designed to |
129 | automatically generate test result files, in the same directory as the | 124 | automatically generate test result files, in the same directory as the |
@@ -131,6 +126,17 @@ targeted patch files but with .testresult as an extension. These contain | |||
131 | the entire output of the patchtest run for each respective pass, | 126 | the entire output of the patchtest run for each respective pass, |
132 | including the PASS, FAIL, and SKIP indicators for each test run. | 127 | including the PASS, FAIL, and SKIP indicators for each test run. |
133 | 128 | ||
129 | ### Running Patchtest Selftests | ||
130 | |||
131 | Patchtest also includes selftests, which are currently in the form of | ||
132 | several contrived patch files and a runner script found in | ||
133 | `meta/lib/patchtest/selftest/`. In order to run these, the | ||
134 | `meta-selftest` layer must be added to bblayers.conf. It is also | ||
135 | recommended to set BB_SERVER_TIMEOUT (and thus enable memory-resident | ||
136 | bitbake) in local.conf to reduce runtime, as the bitbake startup process | ||
137 | will otherwise add to it significantly when restarted for each test | ||
138 | patch. | ||
139 | |||
134 | ## Contributing | 140 | ## Contributing |
135 | 141 | ||
136 | The yocto mailing list (openembedded-core@lists.openembedded.org) is used for questions, | 142 | The yocto mailing list (openembedded-core@lists.openembedded.org) is used for questions, |