this is a decent repository of wish list items, but for faster action you should also make your case to the CC devel mailing list. See the guidelines on making a feature request here: http://cruisecontrol.sourceforge.net/decisions.html
Also see DeveloperToDoList.
WishGranted
Let the schedule tag accept a cron expression as an attribute (use Quartz?). I would like my build process to kickoff around early morning and lunchtime each weekday, with my common project building a few minutes before the rest of my projects
When sending an e-mail it would be nice be able to specify attachments, i.e. so that the e-mail can include clover pdf reports etc....
I wish there was a keen little command line binary (perl?) that would pose some setup questions to start, using MY repository instead of a hello world, and offer a crude interface for configuring the content & format of the buildresults jsp, the html publisher, schedule, and modificationset. Maybe a 'Solaris package' that would run on everything.-- R
A good suggestion yet to be implemented:
- change the web.xml to point to config.xml and get the needed parameters out of there (once and only once)
Another suggestion is for the reporting pages to autoconfigure using JMX.
Both of these suggestions, however, assume that the reporting app is on the same server as the build server, and thus that the build server's settings would be relevant to the reporting app...
Like many programming shops, our development focuses around our bug tracking system (in this case, Bugzilla). I recently applied the patch to ViewCVS for links from CVS check in comments to a bug tracking system, and I would like to see similar functionality in CruiseControl.
In ViewCVS, you specify a bug tracking prefix URL (like "http://mycompany.com/tracker?id=") and it matches strings like "bug #123" with the numerical part as the suffix, then creates a link from "bug #123" to http://mycompany.com/tracker?id=123. This works well for most bug tracking systems which use numerical IDs.
Here's the regex from the View CVS patch (python):
bug_prefix = [Bb][Uu][Gg]\D{1,3}
So, that's any variation of the word "bug" followed by up to three spaces of non-digit characters.
– LukeFrancl
Would it be possible for the reporting webapp to display an error message when it misses the rights to write the _cache directory? See the "Why can't I see the details on the web page? Why is the buildresults page blank?" FrequentlyAskedQuestions. This one really puzzled me for some time. Such a message would immediately let you know what's wrong. – DbR
In the webapp, the tabs that are off (initially Test Details, XML Log File and Control Panel) are presented by an image with black text on very dark gray background. At least on my screen setup, it's completely invisible (not enough contrast), I did not even see there were any tabs. It might be fine for people who set luminosity high, but it seems wrong that this is the default. I think this should be changed, either with higher-contrast images, or by using plain text plus styles, which at least would allow users to easily change the setup. – DbR
Look again – the tabs are plain text with styles ('tab', 'tab-link', and 'tab-selected'). Enjoy.
Wrap XmlLogger in XmlListener so that it obeys debug level (submitted by BharatMediratta). This patch wraps XmlLogger in an XmlListener which determines the appropriate Logger message level from a system property. This patch resolves the problem that when you're using a listener the XML output file gets bloated with debug output. The patch consists of changes to AntBuilder, AntBuilderTest, and a new file called XmlListener. It was generated against CVS as of 3/13 16:00 PST. The patch can be found here: http://sourceforge.net/mailarchive/forum.php?thread_id=1828165&forum_id=2202 (apologies for the user list link, but I didn't want to put the code in here, either and the user list link seemed like the least offensive of the two choices).
Adding XSL files
When you want to add a XSL-file to CC. You need to change the method
xslFileNames in HTMLEmailPublisher.java
which is somewhat of a pain. Especially when you have defined the path to the xsl folder anyway.
I'll look into this one; however, remember that the order of stylesheet inclusion is important. Maybe we can shift to using a numeric-based prefix so we can get auto-ordering?
Some facility to clean up the logs automatically. Keep the last good one (too show it worked at some point), the first broken one (to show where it went wrong), the current broken one (to show its still broken), and the build fixed log. Then after the next success you could clear all that out and just keep the last N logs.
Make the spamwhilebroken="false" setting send an email message if NEW changes were added that still cause the build to break. For example in 2.1.5 if while trying to fix problem A I succeed but cause problem B I will not get an email telling me what the problem is NOW (or even that it built at all) because it would be stopped by the spamwhilebroken switch.
It would be nice to be able to return info back to the CCNET process, particularly the build label that my NAnt script chose (usually based on things a little more complicated than simple incrementation of a number). This could maybe be done by the NAnt script setting a setting in an XML file, maybe...
Make the notification attribute of the email publisher group element a bit more flexible. For example, the project manager doesn't need to know if everything's fine, only when there's an issue. Likewise, the HCI and testing people don't need to know if a build has failed during the compilation stage, since it won't affect them (it won't deploy the build unless it can compile it, and they only get ne stuff after a deployment).
The possible conditions of a notification:
fail
broken (was working, now failing)
success
fixed (was failing, now working)
change (either 'broken' or 'fixed')
always (every time a build happens, no matter what)
I'd like to see the WebApp have a way to show me which builds are in the queue for building. We have over a dozen projects defined, and sometimes a single change to a highly common part (like ant build macros) trigger all the projects to rebuild. Then another developer wants to see why his project specific change is taking so long to build-- he has no way to check the build queue.
Just a friendly suggestion for the designers of the cruise control webapp. Make your taglib tags much more modular. Make them less dependant on nesting. And output less HTML from them. You are abusing taglibs and it's making me cry. Significant (important) pieces of the CC webapp's layout are tucked away in HTML that is output by tag libraries. I shouldn't have to recompile a taglib JAR to reformat the page. Reduce the number of tags used. Consider getting rid of all or almost all tag "nesting" dependencies. This only encourages rigid relationships between data structure and data view. P.S. Thank you for Cruise Control!
