Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Bug of the Month - May 2011

Matt Schuetze1 Absent Member.
Absent Member.
0 0 975

This month I’ll share a bug report that amounts to undocumented capability, namely using DevPartner command line utilities to automatically run inspections within a continuous integration environment. The story is a recent customer care case regarding DevPartner Code Review run under an automatic build system. In this case, the customer was trying to call Code Review’s command line tool –a utility named CRBatch --underneath her instance of Cruise Control. We like this usage model because you can fire off a hands-free code review and automatically have a solution-wide review completed after each build triggered by a source file commit. The reported behavior was that CRBatch worked from a command prompt, but appeared to hang when executed from inside Cruise Control. In this case, it only took a little bit of effort to come up with the proper Cruise Control configuration to make CRBatch work perfectly, even though there are no published instructions available on how to decorate your Cruise Control configuration to make this happen. Just because something isn't documented doesn't mean it won't work. This was a case where getting our hands dirty came in handy.

Here is the sample configuration setup named ccnet_CR_CC.config.xml  rigged up for machine name DPHOST1050 machine with test solution CSharpApp.sln in folder C:\Testapps\CSharpApp:

  

<cruisecontrol>
  <project name="Test_CR_Batch">
    <workingDirectory>C:\Testapps\CSharpApp</workingDirectory>
    <artifactDirectory>C:\Testapps\CSharpApp\Artifact</artifactDirectory>
    <webURL>http://DPHOST1050/ccnet</webURL>
    <!--    <publishExceptions>true</publishExceptions> -->

    <triggers>
      <intervalTrigger name="continuous" seconds="120"  buildCondition="ForceBuild" initialSeconds="5" />	
    </triggers>  
    <tasks>
	<exec>
  	  <executable>$(crbatch105)</executable>	
          <buildArgs>/f C:\Testapps\CSharpApp\CSharpApp.crb /vs 9.0</buildArgs>
	</exec>
	<exec>
	  <executable>$(crexport105)</executable>
          <buildArgs>/f C:\Testapps\CSharpApp\CSharpApp.dpmdb /e
          C:\Testapps\CSharpApp\CSharpApp.CodeReviewResults.xml</buildArgs>
	</exec>
    </tasks>
    <publishers>
	<merge>
         <files>
	     <file>C:\Testapps\CSharpApp\CSharpApp.CodeReviewResults.xml</file>
	     <file>C:\Testapps\CSharpApp\Mixdbld.log</file>
	  </files>
	</merge>
	<xmllogger/>
    </publishers>
  </project>
</cruisecontrol>

 

The key item that makes this configuration effective is the batch directive file CSharpApp.crb fed to the CRBatch utility. It’s a modest response file that is auto-generated by using Code Review in the Visual Studio UI, so recycling it makes the call to then run CRBatch from a command line much more compact. The crucial items inside it are the path to the solution file CSharpApp.sln, the choice of ruleset, and the paths to target output session file CSharpApp.dpmdb and summary report CSharpApp.htm.

REM * DevPartner Code Review Batch Configuration File *
[SOLUTION]
SOLUTION=C:\Testapps\CSharpApp\CSharpApp.sln
RULESET=DEFAULT
UNCALLED=1
METRICS=0
NAMING=1
UseVSNETNaming=1
AnalyzeNamespaces=1
AnalyzeClasses=1
AnalyzeInterfaces=1
AnalyzeDelegates=1
AnalyzeEvents=1
AnalyzeEnums=1
AnalyzeStructs=1
AnalyzeParameters=1
AnalyzeMethods=1
AnalyzeVars=1
AnalyzePublicsOnly=1
UseCamelOnLocals=1
Dictionary=0
CodeReviewVersion=10.5 Build 257
SESSIONFILE=C:\Testapps\CSharpApp\CSharpApp.dpmdb
SUMMARYFILE=C:\Testapps\CSharpApp\CSharpApp.htm 

The rest of the Cruise Control configuration pertains to triggering and reporting, and the other flags in the .crb file control the session data collected. However, if those reporting tags are not set up right, there is sincere chance that CRBatch won’t fire as expected, which is the trap the customer fell into. As you rework this configuration to apply it to your own Cruise Control instance, it’s also important to ensure the startup environment for Cruise Control binds values for CRBatch and CRExport, as embodied in this batch script:

set crbatch105=C:\Program Files (x86)\Micro Focus\DevPartner Studio\CodeReview\crbatch.exe
set crexport105=C:\Program Files (x86)\Micro Focus\DevPartner Studio\CodeReview\crexport.exe
call C:\Program Files (x86)\CruiseControl.NET\server\ccnet.exe -c:ccnet_CR_CC.config.xml

This is where variables $(crbatch105) and $(crexport105) are resolved. You could alternatively put the CodeReview install folder in your system path environment variable and use the EXE names directly, or copy/paste their full paths into the configuration file.

 

So this writeup gives an example on how to properly generate Code Review session data on a check in. Even though this example is a grossly simplified from a fully tricked-out Cruise Control script, hopefully it demonstrates the key items you’d need to setup your own script and generate session data. Applying this to your own instance may require slimming down your CRBatch reponse file to run certain projects or be expanded to multiple solutions. Hooking in exported data into the Cruise Control report system provides another interesting use case and remains an exercise for another article. Hopefully a customer asks for that so I can write it up.

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.