Based on Jenkins 1.509 and Checkstyle 5.6.
Now we need practising code review, as a step of BVT of course. The ideal solution is based on Sonar and its checkstyle plugin. But I am not very familiar with sonar's java runner and other features. So I decided to use some "plain" method to embed code review into the process of BVT.
Preparations
-
Install checkstyle plugin of jenkins;
-
copy checkstyle-5.6-all.jar to /opt/checkstyle;
-
create a code review rule file tyRules.xml at /opt/checkstyle:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
-
Project -> Configuration -> Source Code Management -> Subversion -> Repo URL: svn://localhost/ServerMeter
-
Project -> Configuration -> Post-build Actions -> Publish Checkstyle analysis results: */codeReview.xml;
-
Project -> Configuration -> Post-build Actions -> E-mail Notification: ...
As part of ant build
- add a target "checkcode" in build.xml:
<?xml version="1.0" encoding="UTF-8"?>
- Jenkins setup: Project -> Configuration -> Build -> Invoke Ant -> Targets: checkcode;
PROS: simple config, with the power of ant;
CONS: build scripts of every project have to be modified, which violates the DRY principle;
As an independent step in build process
Jenkins setup: Project -> Configuration -> Build -> Execute shell:
rm -rf build mkdir build find . -depth -name .svn -exec rm -fr {} \; java -jar /opt/checkstyle/checkstyle-5.6-all.jar -c /opt/checkstyle/tyRules.xml -r src -f xml -o build/codeReviewResult.xml
PROS: no need to modify any thing in project, do one thing in only ONE place;
CONS: there are some dirty work in shell script, for example you have to delete and create build folder manually (otherwise checkstyle report can not be created correctly), and remove all .svn folder recursively (otherwise checkstyle will find some duplicate codes in normal code file and backup file in .svn folder).