Looking at the build log files, they seem to come in two flavours? Examples:
log20090116150101.xml <-- for a failed build and log20090119160011Lbuild.91.xml <-- for a successful build This seems to be, log<YYYYMMDDHHMMSS>.xml and log<YYYYMMDDHHMMSS>LBuild.<revision num>.xml Seeing as I need pretty much all the information within these log files I was hoping that at the end of the build process, as the last entry in the Publisher Block, that I could simply append the whole log file for the current build to the end of a digest.xml file wrapped between <digestEntry> ... log file ... </digestEntry> At what point does the log file get written and closed being correctly terminated with </cruisecontrol> and is there an easy way of getting hold of the log file name and passing it into a <exec/> block? If I can't do this I have to effectively manually recreate the log file (becaue I need pretty much everything in it). Regards, Shaun On 22 Jan, 15:03, CinnamonDonkey <[email protected]> wrote: > That is going to be a really great feature! > > But it still does not solve the problem of a very cluttered web dash. > > Regards, > Shaun > > On 22 Jan, 11:53, Ruben Willems <[email protected]> wrote: > > > Hi > > > good point, > > about the force build stuff, hopefully the security branch will be merged > > soon. > > Than it is possible to define users who may do a force build, or something > > else. > > > The merge is planned for 'soon', but an exact date is not yet known. > > You can find documentation about this security branch at > > :http://csut017.wordpress.com/category/cruisecontrolnet/security-cruis... > > > with kind regards > > Ruben Willems > > > On Thu, Jan 22, 2009 at 12:48 PM, CinnamonDonkey < > > > [email protected]> wrote: > > > > The problem with creating multiple projects is that the CCNET dash > > > gets cluttered with projects design for special conditions but all > > > basically the same project. There is no means of hiding them or > > > preventing the end user from doing a force on these special condition > > > projects. > > > > Also, you have to explain to the end user what each of these projects > > > represent and why they should not be doing a forced build on them. > > > With 30+ programmers that's a lot of information to pass out. > > > > Whats more, if like us you have 9 different products, the last thing > > > you want is 9 products x N special conditions cluttering up the web > > > dash. > > > > For the one particular product I am working on (trying to provide my > > > lead with the requested features) we already have: > > > > Product-Daily > > > Product-Incremental > > > Product-Incremental.onFailRebuildFromScratch > > > > Now we will have additionally: > > > > Product-Daily.standardReporting > > > Product-Daily.digestReporting > > > Product-Incremental.standardReporting > > > Product-Incremental.digestReporting > > > Product-Incremental.onFailRebuildFromScratch > > > > Can you see how this gets a bit messy? It's much better that the end > > > users just see: > > > > Product-Daily > > > Product-Incremental > > > > Much cleaner and less oppertunity for error (they don't need to know > > > about these special hidden conditional builds). > > > > RE: Complexity... > > > > I see it as optional advanced usage. A powerful feature available to > > > the user if they wish to use it. > > > > I also see this solution as being easier than having to keep writing > > > our own scripts and modifying them to detected different conditions > > > and behave differently. > > > > Regards, > > > Shaun > > > > On 22 Jan, 11:17, Ruben Willems <[email protected]> wrote: > > > > Hi > > > > > point one : > > > > it is easier if you set up 2 ccnet projects, > > > > so these can have their own email configuration. > > > > > you can play around with xsl, add if statements so some part of the info > > > > will not be rendered at certain conditions, but the same mail is sent to > > > > all the users in the subject field. > > > > So if you can find a logic way to exclude team leads to get a mail > > > > you could keep 1 ccnet project, with a tweaked xsl file. but this makes > > > the > > > > configuration very complex. > > > > > point 2 is not possible for the moment, > > > > > would that not make ccnet to complex? > > > > why not set up 2 projects? > > > > is there a real benefit of having just 1 ccnet project? > > > > > with kind regards > > > > Ruben Willems > > > > > On Thu, Jan 22, 2009 at 11:55 AM, CinnamonDonkey < > > > > > [email protected]> wrote: > > > > > > Thanx for the reply Ruben - it's cleared up a few things for me. > > > > > > A few more questions (sorry, I never run out of questions ;-) : > > > > > > 1. Is it possible to apply different email rules based on the trigger > > > > > name? We want the Team leads to only receive the digest report once a > > > > > week whilst everyone else recieve daily reports IF the build fails > > > > > (but not the lead). > > > > > > 2. I'm not sure if this is already possible,... erm, it could be a > > > > > feature request, example: > > > > > > ... > > > > > > <triggers> > > > > > <scheduleTrigger time='20:00' > > > > > buildCondition='ForceBuild' > > > > > name="standardReporting" > > > > > > <weekDays> > > > > > <weekDay>Monday</weekDay> > > > > > <weekDay>Tuesday</weekDay> > > > > > <weekDay>Wednesday</weekDay> > > > > > <weekDay>Thursday</weekDay> > > > > > </weekDays> > > > > > </scheduleTrigger> > > > > > > <scheduleTrigger time='20:00' > > > > > buildCondition='ForceBuild' > > > > > name="digestReporting" > > > > > > <weekDays> > > > > > <weekDay>Friday</weekDay> > > > > > </weekDays> > > > > > </scheduleTrigger> > > > > > </triggers> > > > > > > ... > > > > > > <tasks> > > > > > <standardReporting> > > > > > <exec> > > > > > ... Tasks that only occur for triggers > > > > > where name = standardReporting > > > > > </exec> > > > > > </standardReporting> > > > > > > <digestReporting> > > > > > <exec> > > > > > ... Tasks that only occur for triggers > > > > > where name = digestReporting > > > > > </exec> > > > > > </digestReporting> > > > > > </tasks> > > > > > > ... > > > > > > <publishers> > > > > > <standardReporting> > > > > > ... Tasks that only occur for triggers > > > > > where name = standardReporting > > > > > </standardReporting> > > > > > > <digestReporting> > > > > > ... Tasks that only occur for triggers > > > > > where name = digestReporting > > > > > </digestReporting> > > > > > <publishers> > > > > > > Hopefully an example speaks better than a 1000 words ;-), the idea is > > > > > that the trigger name can be used to create sections within the task > > > > > blocks that can partition behaviour based on the trigger that fires. > > > > > Anything outside these sections will run a normal. > > > > > > Is this possible? > > > > > > Shaun > > > > > > On 21 Jan, 15:36, Ruben Willems <[email protected]> wrote: > > > > > > Hi > > > > > > > why would you need to make a new email publisher? > > > > > > > as far as I know the story, you have a project for daily digests, > > > and a > > > > > > project for weekly digests > > > > > > (or 1 project in which you differentiate via the triggername) > > > > > > > anyway, the daily reports make an xml file > > > > > > <dailyreports> > > > > > > <fancy data/> > > > > > > </dailyreports> > > > > > > > which get merged via the file merge publisher > > > > > > > and the weekly reports make another xml file with this layout > > > > > > <weekreports> > > > > > > <fancy data/> > > > > > > </weekreports> > > > > > > which also get merged > > > > > > > now in the email publisher, > > > > > > you use 2 xsl files > > > > > > dailyreports.xsl > > > > > > weeklyreports.xsl > > > > > > > These are the same as the ones in the dashboard, so you have them > > > already > > > > > > > normally a 'build' only contains or daily, or weekly data, but > > > > > > should > > > it > > > > > > contain both > > > > > > both data will be visible in the mail > > > > > > > problem solved ;-) > > > > > > > with kind regards > > > > > > Ruben Willems > > > > > > > with kind regards > > > > > > Ruben Willems > > > > > > > On Wed, Jan 21, 2009 at 4:25 PM, CinnamonDonkey < > > > > > > > [email protected]> wrote: > > > > > > > > It would be really nice if the digest reports could look and feel > > > the > > > > > > > same as the daily reports. To achieve this I guess I would have to > > > > > > > write a new email publisher based on the existing publisher which > > > can > > > > > > > use the existing .xsl files. > > > > > > > > I was wondering how I would go about doing this? How are > > > > > > > publishers > > > > > > > created, in what language? Where is the source code for the > > > existing > > > > > > > emailPublisher? > > > > > > > > Cheers, > > > > > > > Shaun > > > > > > > > On 19 Jan, 10:08, CinnamonDonkey <[email protected]> > > > > > > > wrote: > > > > > > > > Cheers Ruben, the response is very much appreciated :) > > > > > > > > > On 19 Jan, 10:01, Ruben Willems <[email protected]> wrote: > > > > > > > > > > Hi > > > > > > > > > > that's some request ! > > > > > > > > > > it can be done, although it will require some work on your > > > > > > > > > part > > > ;-) > > > > > > > > > > First be sure that you use the every project uses the > > > statistics > > > > > > > publisherhttp:// > > > > > > > confluence.public.thoughtworks.org/display/CCNET/Statistics+Pu... > > > > > > > > > This will create a file, containing all the statistics you > > > need, > > > > > you > > > > > > > can > > > > > > > > > alter the metrics to be gathered, but I have not done this yet > > > > > myself. > > > > > > > > > the file is located in the artifact folder of the > > ... > > read more »
