Performing reviews can be an overwhelming process. The more complex the base, the more comprehensive reviews end up. Building that functionality into the build itself is a full time job. When a new check is added there is a good chance the existing code has problems and often maintainers just want to prevent new bits from making the existing problem worse.
This is where Apache Yetus' precommit utilities come into the picture.
All patches to the source base go through a test that does some (relatively) light checking to make sure the proposed change does not break unit tests and/or passes some other prerequisites such as code formatting guidelines. This is meant as a preliminary check for reviewers so that the basic patch is in a known state and for contributors to know if they have followed the project's guidelines. This check may also be used by individual developers to verify a patch prior to sending to the QA systems.
Almost all of the precommit components are written in bash for maximum portability. As such, it mostly assumes the locations of commands to be in the file path. However, in many cases, this assumption may be overridden via command line options.
These components are expected to be in-place for basic execution:
For Solaris and Solaris-like operating systems, the default location for the POSIX binaries is in /usr/xpg4/bin and the default location for the GNU binaries is /usr/gnu/bin.
Features are plug-in based and enabled either individually or collectively on the command line. From there, these are activated based upon tool availability, the languages being tested, etc. The external dependencies of plug-ins may have different licensing requirements than Apache Yetus.
These plug-ins are native to Apace Yetus and are (usually!) always available:
Automation and Isolation:
Compiler Support:
Commonly Parsed File Formats:
Language Support, Licensing, and more:
precommit also comes with some utilities that are useful in various
capacities without needing to use the full test-patch runtime: