The JSP is a very neat feature of the tool, and makes Cruise Control more appealing than [TinderBox] and AntHill as a result of its simplicity and elegance. The Cruise Control Home presents this beautifully at the following URL:

http://cruisecontrol.sourceforge.net/reporting/jsp/index.html

Howtos:

PasswordAuthenticatingThe JSP

JSPExpectsLogDirectoryNameEqualsProjectName

One note is the JSP is optional. See discussion below about HTMLEmailPublisher.

Customising the JSP Interface

Now that we've moved to using the HtmlEmailPublisher the JSP is almost never used, though it is still useful for historical questions like "when did the build last pass?" or "how frequently has the build been failing?" or "was the build already broken before I checked it?" - JeffreyFredrick

I notice the same. The JSP is more for historical information. I'm thinking we should make the appearance of the link on the mail optional. - JasonYip

From my own experience, I think having the link applies more specifically to the people that want notification about all builds. I find that I'm better able to track project progress on a day to day basis when I can check the jsp at the end of the day, but my team seems to use the e-mail notification as a kind of status check as they go. Alias mappings may be the place to toggle presentation of the link in the notification message (opt-in), but having the link as an opt-out for all builds. Ours is a very simple use case, tho. - R

Please do keep the link in as default. Our developers use it to track down changes and build breakages. Some of our developers don't get mail when the build breaks. They only get it when they commit changes. The link gives them a way to see if it was their changes or who broke it before they committed changes. Making it optional is fine, but on should be the default in my opinion.--deanhiller

Ditto - please please keep the link to the JSP. Optional OK but by default it should be present. We only put basic summary information in the HTMLEmailPublisher email - enough to know if a build passed of failed and if so where (compile test etc) + plus the mod file list of course. We use the JSP to give very detailed information such the full compiler/unittest log. Also we have added drill down links from the modified file list to ViewCVS to see file diffs to last good build (see IntegratingCruiseControlWithViewCvs). An import thing for my team is working out if they commit a file and subsequently get a "the build is broken" mail, is "was the build already broken". They get this info from the JSP and no where else --Tony Cook

The change to make the link optional is now in CVS. The logic is simple: if you don't want the link, don't provide the buildServletUrl parameter. Thus if you're already using this publisher you should see no change. --Jtf

We've just finished writing a DBPublisher so I expect our use of the JSP to further diminish. It is now much easier to get a sense of the build history by looking at a report against the database of build results. There's still more information in the JSP, so it is good if you want the details of what files were modified in a given build or if you want to see the detailed compiler/test errors.

While I think a database publisher might be really good, I would still want a web interface.

Having got myself into a position where I'm setting up a build farm for multiple projects, the web interface gives me a really easy way to glance over several projects. It'll be even better when I add the multi-project summary page in the next few days/weeks.

Besides, the web page gives me something easy to demonstrate to my boss. "See, we ran this build on Wednesday, and these tests were passing. On Thursday, after the DB was rebuilt, these tests are now failing." Simple, high-impact, and easy enough for a PHB to follow. - rw

Note: there was a change in 2.3.1 where instead of transforming the log file it was returned as an xml file to the client (Jira CC-294). The problems that Glenn describes below with this feature were not commonly reported in CC 2.3.1 but rather something he and a few others saw in his environment; other people reported using the XML Log File tab without problems. But even for people who don't experience any problems with this feature but prefer to see the log file rendered on the page instead of downloaded this technique is useful. It also illustrates how easy it is to add a custom tab and xsl transform to the CC reporting app.

I wanted to share some changes that I made to CruiseControl 2.3.1 to address some problems I found.

First, with 2.3.1, if you click on the "XML Log File" tab, you will be returned a direct path to the XML log file. There are several problems with this: first, there is no protocol specification (e.g., "file://"). The second problem is that if it was specified, the path would still be relative to the server machine. If you are on a client machine, the path is meaningless.

So, my changes are to main.jsp, as follows:

70,71c70,72
<               <cruisecontrol:xsl url="logs_url" serveContent="false"/>
<               <cruisecontrol:tab name="log" url="<%=logs_url%>" label="XML Log File" />
---
>             <cruisecontrol:tab name="log" label="XML Log File" >
>                 <cruisecontrol:xsl url="logs_url" xslFile="/xsl/logfile.xsl" serveContent="true"/>
>             </cruisecontrol:tab>

In 2.4 "after" lines are the same but the lines to change are:

<cruisecontrol:loglink id="logs_url"/>
              <cruisecontrol:tab name="log" url="<%=logs_url%>" label="XML Log File" />

After this change, the logfile.xsl is used to render the log file. However, the formatting doesn't honor the spacing and line breaks generated by the XSL. To address this problem and add some syntax coloring, I've updated the logfile.xsl file, as per the following:

67a68,75
>     <style type="text/css">
>       SPAN.element-name { color: #39c; font-weight: bold; }
>       SPAN.attribute-name { color: #0c0; }
>       SPAN.text-node { color: #666; }
>       CODE.xml-log { font-size: 0.9em; }
>     </style>
>
>     <PRE><CODE class="xml-log">
68a77
>     </CODE></PRE>
195c204
<     <xsl:value-of select="$text"/>
---
>     <span class="element-name"><xsl:value-of select="$text"/></span>
200c209
<     <xsl:value-of select="$text"/>
---
>     <span class="attribute-name"><xsl:value-of select="$text"/></span>
249c258
<     <xsl:call-template name="escape-markup-characters">
---
>     <span class="text-node"><xsl:call-template name="escape-markup-characters">
251c260
<     </xsl:call-template>
---
>     </xsl:call-template></span>

The complete XSL file can be found here: logfile.xsl.

The result is a much more usable log file viewer. (Posted by Glenn Boysko, February 6, 2006 at 11:00am EST)