patchtest.README 6.9 KB

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