Patchtest: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
No edit summary
Line 12: Line 12:


==== FAIL: test shortlog length: Edit shortlog so that it is 90 characters or less (currently X characters) ====
==== FAIL: test shortlog length: Edit shortlog so that it is 90 characters or less (currently X characters) ====
This failure indicates that the shortlog (i.e. the subject line) for the patch is so long that it may not be easily readable on some mail clients. Some subject prefixes (e.g. the branch name when submitting a patch for an older release) may unavoidably inflate the length, but the shortlog should be kept as short and concise as possible so that it is clear what the patch does and what it changes. Extra information can always be provided in the commit message.
==== FAIL: test lic files chksum modified not mentioned: LIC_FILES_CHKSUM changed without "License-Update:" tag and description in commit message (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned) ====
Patchtest checks to ensure that any changes made to LIC_FILES_CHKSUM lines (including checksums for new files) are accounted for in the commit message with at least one "License-Update: <reason>" tag. If this is not present, then this test will fail.
==== FAIL: test CVE presence in commit message: A CVE tag should be provided in the commit message with format: "CVE: CVE-YYYY-XXXX" (test_mbox.TestMbox.test_cve_presence_in_commit_message) ====
Whenever a submission adds a CVE patch, patchtest will check both the patch '''and the parent mbox's commit message''' for a "CVE: CVE-YYYY-XXXX" tag. While this has historically not been required, including the tag in both locations improves review and maintenance.

Revision as of 14:48, 30 October 2023

Patchtest

Patchtest is a tool designed for improving the quality of Yocto Project and OpenEmbedded contributors' patch submissions, while simultaneously reducing the level of review effort required from project maintainers. It does this by providing a set of scripts that users can test their patches with prior to submission ("host" mode), and which can be used as part of an automated service that provides periodic feedback for patches received by Patchwork ("guest" mode).

Using Patchtest

See the patchtest README for instructions on how to use patchtest in your local workspace, and the meta-patchtest README for details on host mode setup.

Patchtest Feedback Guidelines

The patchtest feedback email is designed to provide concise instructions when one or more of the tests has failed, but additional information on specific failures is provided below:

FAIL: test shortlog length: Edit shortlog so that it is 90 characters or less (currently X characters)

This failure indicates that the shortlog (i.e. the subject line) for the patch is so long that it may not be easily readable on some mail clients. Some subject prefixes (e.g. the branch name when submitting a patch for an older release) may unavoidably inflate the length, but the shortlog should be kept as short and concise as possible so that it is clear what the patch does and what it changes. Extra information can always be provided in the commit message.

FAIL: test lic files chksum modified not mentioned: LIC_FILES_CHKSUM changed without "License-Update:" tag and description in commit message (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)

Patchtest checks to ensure that any changes made to LIC_FILES_CHKSUM lines (including checksums for new files) are accounted for in the commit message with at least one "License-Update: <reason>" tag. If this is not present, then this test will fail.

FAIL: test CVE presence in commit message: A CVE tag should be provided in the commit message with format: "CVE: CVE-YYYY-XXXX" (test_mbox.TestMbox.test_cve_presence_in_commit_message)

Whenever a submission adds a CVE patch, patchtest will check both the patch and the parent mbox's commit message for a "CVE: CVE-YYYY-XXXX" tag. While this has historically not been required, including the tag in both locations improves review and maintenance.