Wingman Analyzers

Below is a description of the analysis performed by Wingman. This list will grow in the future. Please let us know if you find that some information is missing.

Tests

A pull request may not break any existing unit and integration tests. Failures must be addressed in the same PR (preferably in the same commit) as the required code. If a test was broken before the pull request, we also ask that they be fixed. It is not ok to ignore tests which were failing previously. One cannot determine with a reasonable certainty that regressions were not introduced by the new runtime code unless all of the tests have completed and exercised all code paths that it must. Therefore:

All failures must be addressed prior to accepting a pull request, wether or not it existed before the current pull request.

For more information regarding testing best practices, please refer to our documentation on best practices.

Build

Some of the Pentaho projects based on Ant have build files that are shared across other projects. These are the foundation for the builds. We cannot modify these files on a per-project basis. For any given project, if changes are requires for this specific project, we must make the changes on the build.xml file which imports the shared resources. Any changes made to the shared build files (subfloor.xml, subfloor-ee.xml and others) will be overwritten the next time the build folks push changes across all projects. 

If you believe that these shared files must be modified for one reason or another, please log a ticket in our Jira system, or get in contact with buildteam@pentaho.com.

Style

All of the code for Pentaho projects must adhere to styling rules defined in Checkstyle format. To be able to run these tests locally, you will need to invoke the Ant target "checkstyle". Alternatively, you can also configure your IDE to flag the styling issues right inside your code. Consult the following help sections to configure your IDE.

Coverage

As a rule of thumb, we require all new code to be covered by unit and integration tests by a factor of about 80% of their instructions. As far as pre-existing code goes, we ask that coverage goes up and does not drop significantly. 

If you observe that your coverage does drop but there is an explanation for it (like removing old well tested code) simply add a comment to that effect on your pull request.

If you need help figuring out which parts of the code are tested, please consult the help sections related to using Sonar's coverage metrics.

License

All Pentaho code must have a proper file header which includes its applicable license and the right copyright years. For new code contributed to existing projects, the same license usually applies and can be copied over the new files. Note that there are two exceptions to this.

• New projects: For new projects, please speak with your manager and/or the intellectual property folks within the devops team.
• Copied code: If your code was copied and/or loosely inspired from some other place, you might not be able to include it in a particular project, depending on the licenses of both. Should this happen, please speak with your manager and/or the intellectual property folks within the devops team.