Everyone’s time is valuable. The quicker contributors can get feedback and iterate, the more likely and faster their contribution will get checked in. A committer should be able to focus on the core issues of a contribution rather than details that can be determined automatically.
Precommit checks should be fast. There is no value in testing parts of the source tree that are not immediately impacted by a change. Unit testing is the target. They are not a replacement for full builds or integration tests.
Many open source projects have a desire to have this capability. Why not generalize a solution?
In many build systems (especially with maven), a modular design has been picked. Why not leverage that design to make checks faster?
Projects that use the same language will, with a high degree of certainty, benefit from the same types of checks.
Portability matters. Tooling should be as operating system and language agnostic as possible.
test-patch works effectively under several different phases:
This is where test-patch configures and validates the environment. Some things done in this phase:
Checks done here are fatal.
This acts as a verification of all of the setup parts and is the final place to short-cut the full test cycle. The most significant built-in check done here is verifying the patch file is a valid.
Tests that only require the patch file are run. Note that the repository is still from the initial checkout!
When compilation must be done, we follow these five steps:
The first time this is done is with the pristine checkout. This is called the
branch compile. For this pass, this is where the ‘before’ work is handled. Some things that typically get checked in this phase:
This step is to wipe the repository clean back to a pristine state such that the previous cycle will not impact the next cycle.
The patch gets applied.
Now that the patch has been applied the steps to compile we outlined in the compilation (branch) phase are repeated but with the patch applied. This is where a lot of ‘after’ checks are performed.
Since unit tests are generally the slowest part of the precommit process, they are run last. At this point, all the prerequisites to running them should be in place and ready to go.
Finally, the results are reported to the screen and, optionally, to JIRA and/or whatever bug system has been configured.
The basic workflow for many of the sub-items in individual phases are:
As one can see, the modules list is one of the key inputs into what actually gets executed. As a result, projects must full flexibility in either adding, modifying, or even removing modules from the test list. If a personality removes the entire list of modules, then that test should just be ignored.