scripts/patchtest.README: cleanup, add selftest notes

Make some minor fixes to grammar and layout, and add a short new section
describing how to setup and use the patchtest selftests properly.

(From OE-Core rev: 264185d2cfa31b1cf2534a8de21e4b17bb5bbf79)

Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Trevor Gamblin 2024-07-30 17:19:46 -04:00 committed by Richard Purdie
parent 4954be685f
commit 6c1e2d7971

View File

@ -3,40 +3,35 @@
## Introduction ## Introduction
Patchtest is a test framework for community patches based on the standard Patchtest is a test framework for community patches based on the standard
unittest python module. As input, it needs tree elements to work properly: unittest python module. As input, it needs three elements to work properly:
a patch in mbox format (either created with `git format-patch` or fetched
from 'patchwork'), a test suite and a target repository. - a patch in mbox format (either created with `git format-patch` or fetched
from 'patchwork')
- a test suite
- a target repository
The first test suite intended to be used with patchtest is found in the The first test suite intended to be used with patchtest is found in the
openembedded-core repository [1] targeted for patches that get into the openembedded-core repository [1], targeted for patches that get into the
openembedded-core mailing list [2]. This suite is also intended as a openembedded-core mailing list [2]. This suite is also intended as a
baseline for development of similar suites for other layers as needed. baseline for development of similar suites for other layers as needed.
Patchtest can either run on a host or a guest machine, depending on which Patchtest can either run on a host or a guest machine, depending on
environment the execution needs to be done. If you plan to test your own patches which environment you prefer. If you plan to test your own patches (a
(a good practice before these are sent to the mailing list), the easiest way is good practice before these are sent to the mailing list), the easiest
to install and execute on your local host; in the other hand, if automatic way is to install and execute on your local host; in the other hand, if
testing is intended, the guest method is strongly recommended. The guest automatic testing is intended, the guest method is strongly recommended.
method requires the use of the patchtest layer, in addition to the tools The guest method requires the use of the patchtest layer, in addition to
available in oe-core: https://git.yoctoproject.org/patchtest/ the tools available in oe-core: https://git.yoctoproject.org/patchtest/
## Installation ## Installation
As a tool for use with the Yocto Project, the [quick start guide](https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html) As a tool for use with the Yocto Project, the [quick start
contains the necessary prerequisites for a basic project. In addition, guide](https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html)
patchtest relies on the following Python modules: contains the necessary prerequisites. In addition, patchtest relies on
several Python modules for parsing and analysis, which can be installed
- boto3 (for sending automated results emails only) by running `pip install -r meta/lib/patchtest/requirements.txt`. Note
- git-pw>=2.5.0 that git-pw is not automatically added to the user's PATH; by default,
- jinja2 it is installed at ~/.local/bin/git-pw.
- pylint
- pyparsing>=3.0.9
- unidiff
These can be installed by running `pip install -r
meta/lib/patchtest/requirements.txt`. Note that git-pw is not
automatically added to the user's PATH; by default, it is installed at
~/.local/bin/git-pw.
For git-pw (and therefore scripts such as patchtest-get--series) to work, you need For git-pw (and therefore scripts such as patchtest-get--series) to work, you need
to provide a Patchwork instance in your user's .gitconfig, like so (the project to provide a Patchwork instance in your user's .gitconfig, like so (the project
@ -123,7 +118,7 @@ The general flow of guest mode is:
-device virtio-9p-pci,fsdev=test_mount,mount_tag=test_mount -smp 4 -m -device virtio-9p-pci,fsdev=test_mount,mount_tag=test_mount -smp 4 -m
2048"` 2048"`
Patchtest runs as an initscript for the core-image-patchtest image and Patchtest is run by an initscript for the core-image-patchtest image and
shuts down after completion, so there is no input required from a user shuts down after completion, so there is no input required from a user
during operation. Unlike in host mode, the guest is designed to during operation. Unlike in host mode, the guest is designed to
automatically generate test result files, in the same directory as the 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
the entire output of the patchtest run for each respective pass, the entire output of the patchtest run for each respective pass,
including the PASS, FAIL, and SKIP indicators for each test run. including the PASS, FAIL, and SKIP indicators for each test run.
### Running Patchtest Selftests
Patchtest also includes selftests, which are currently in the form of
several contrived patch files and a runner script found in
`meta/lib/patchtest/selftest/`. In order to run these, the
`meta-selftest` layer must be added to bblayers.conf. It is also
recommended to set BB_SERVER_TIMEOUT (and thus enable memory-resident
bitbake) in local.conf to reduce runtime, as the bitbake startup process
will otherwise add to it significantly when restarted for each test
patch.
## Contributing ## Contributing
The yocto mailing list (openembedded-core@lists.openembedded.org) is used for questions, The yocto mailing list (openembedded-core@lists.openembedded.org) is used for questions,