patchtest.README 6.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152
  1. # Patchtest
  2. ## Introduction
  3. Patchtest is a test framework for community patches based on the standard
  4. unittest python module. As input, it needs tree elements to work properly:
  5. a patch in mbox format (either created with `git format-patch` or fetched
  6. from 'patchwork'), a test suite and a target repository.
  7. The first test suite intended to be used with patchtest is found in the
  8. openembedded-core repository [1] targeted for patches that get into the
  9. openembedded-core mailing list [2]. This suite is also intended as a
  10. baseline for development of similar suites for other layers as needed.
  11. Patchtest can either run on a host or a guest machine, depending on which
  12. environment the execution needs to be done. If you plan to test your own patches
  13. (a good practice before these are sent to the mailing list), the easiest way is
  14. to install and execute on your local host; in the other hand, if automatic
  15. testing is intended, the guest method is strongly recommended. The guest
  16. method requires the use of the patchtest layer, in addition to the tools
  17. available in oe-core: https://git.yoctoproject.org/patchtest/
  18. ## Installation
  19. As a tool for use with the Yocto Project, the [quick start guide](https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html)
  20. contains the necessary prerequisites for a basic project. In addition,
  21. patchtest relies on the following Python modules:
  22. - boto3 (for sending automated results emails only)
  23. - git-pw>=2.5.0
  24. - jinja2
  25. - pylint
  26. - pyparsing>=3.0.9
  27. - unidiff
  28. These can be installed by running `pip install -r
  29. meta/lib/patchtest/requirements.txt`. Note that git-pw is not
  30. automatically added to the user's PATH; by default, it is installed at
  31. ~/.local/bin/git-pw.
  32. For git-pw (and therefore scripts such as patchtest-get--series) to work, you need
  33. to provide a Patchwork instance in your user's .gitconfig, like so (the project
  34. can be specified using the --project argument):
  35. git config --global pw.server "https://patchwork.yoctoproject.org/api/1.2/"
  36. To work with patchtest, you should have the following repositories cloned:
  37. 1. https://git.openembedded.org/openembedded-core/ (or https://git.yoctoproject.org/poky/)
  38. 2. https://git.openembedded.org/bitbake/ (if not using poky)
  39. 3. https://git.yoctoproject.org/patchtest (if using guest mode)
  40. ## Usage
  41. ### Obtaining Patches
  42. Patch files can be obtained directly from cloned repositories using `git
  43. format-patch -N` (where N is the number of patches starting from HEAD to
  44. generate). git-pw can also be used with filters for users, patch/series IDs,
  45. and timeboxes if specific patches are desired. For more information, see the
  46. git-pw [documentation](https://patchwork.readthedocs.io/projects/git-pw/en/latest/).
  47. Alternatively, `scripts/patchtest-get-series` can be used to pull mbox files from
  48. the Patchwork instance configured previously in .gitconfig. It uses a log file
  49. called ".series_test.log" to store and compare series IDs so that the same
  50. versions of a patch are not tested multiple times unintentionally. By default,
  51. it will pull up to five patch series from the last 30 minutes using oe-core as
  52. the target project, but these parameters can be configured using the `--limit`,
  53. `--interval`, and `--project` arguments respectively. For more information, run
  54. `patchtest-get-series -h`.
  55. ### Host Mode
  56. To run patchtest on the host, do the following:
  57. 1. In openembedded-core/poky, do `source oe-init-build-env`
  58. 2. Generate patch files from the target repository by doing `git-format patch -N`,
  59. where N is the number of patches starting at HEAD, or by using git-pw
  60. or patchtest-get-series
  61. 3. Run patchtest on a patch file by doing the following:
  62. patchtest --patch /path/to/patch/file /path/to/target/repo /path/to/tests/directory
  63. or, if you have stored the patch files in a directory, do:
  64. patchtest --directory /path/to/patch/directory /path/to/target/repo /path/to/tests/directory
  65. For example, to test `master-gcc-Fix--fstack-protector-issue-on-aarch64.patch` against the oe-core test suite:
  66. patchtest --patch master-gcc-Fix--fstack-protector-issue-on-aarch64.patch /path/to/openembedded-core /path/to/openembedded-core/meta/lib/patchtest/tests
  67. ### Guest Mode
  68. Patchtest's guest mode has been refactored to more closely mirror the
  69. typical Yocto Project image build workflow, but there are still some key
  70. differences to keep in mind. The primary objective is to provide a level
  71. of isolation from the host when testing patches pulled automatically
  72. from the mailing lists. When executed this way, the test process is
  73. essentially running random code from the internet and could be
  74. catastrophic if malicious bits or even poorly-handled edge cases aren't
  75. protected against. In order to use this mode, the
  76. https://git.yoctoproject.org/patchtest/ repository must be cloned and
  77. the meta-patchtest layer added to bblayers.conf.
  78. The general flow of guest mode is:
  79. 1. Run patchtest-setup-sharedir --directory <dirname> to create a
  80. directory for mounting
  81. 2. Collect patches via patchtest-get-series (or other manual step) into the
  82. <dirname>/mboxes path
  83. 3. Ensure that a user with ID 1200 has appropriate read/write
  84. permissions to <dirname> and <dirname>/mboxes, so that the
  85. "patchtest" user in the core-image-patchtest image can function
  86. 4. Build the core-image-patchtest image
  87. 5. Run the core-image-patchtest image with the mounted sharedir, like
  88. so:
  89. `runqemu kvm nographic qemuparams="-snapshot -fsdev
  90. local,id=test_mount,path=/workspace/yocto/poky/build/patchtestdir,security_model=mapped
  91. -device virtio-9p-pci,fsdev=test_mount,mount_tag=test_mount -smp 4 -m
  92. 2048"`
  93. Patchtest runs as an initscript for the core-image-patchtest image and
  94. shuts down after completion, so there is no input required from a user
  95. during operation. Unlike in host mode, the guest is designed to
  96. automatically generate test result files, in the same directory as the
  97. targeted patch files but with .testresult as an extension. These contain
  98. the entire output of the patchtest run for each respective pass,
  99. including the PASS, FAIL, and SKIP indicators for each test run.
  100. ## Contributing
  101. The yocto mailing list (yocto@lists.yoctoproject.org) is used for questions,
  102. comments and patch review. It is subscriber only, so please register before
  103. posting.
  104. Send pull requests to yocto@lists.yoctoproject.org with '[patchtest]' in the
  105. subject.
  106. When sending single patches, please use something like:
  107. git send-email -M -1 --to=yocto@lists.yoctoproject.org --subject-prefix=patchtest][PATCH
  108. ## Maintenance
  109. -----------
  110. Maintainers:
  111. Trevor Gamblin <tgamblin@baylibre.com>
  112. ## Links
  113. -----
  114. [1] https://git.openembedded.org/openembedded-core/
  115. [2] https://www.yoctoproject.org/community/mailing-lists/