TASK COMPLETE! Here's how I did it:
1. Two projects exist, the main projectDailyBuild and the projectDigestBuild. 2. projectDailyBuild triggers as normal (Daily at 20:00, Monday- >Friday). At the end of the build process, in the publisher section of the config it calls a python script which works out the file name for the build log just generated. The script Grabs this log file and swapping the <cruisecontrol/> markup for <digestEntry/> it appends the log file to the end of a file called digest.xml. This file lives in the projects working folder (might be better in the artifacts folder to avoid accidental cleaning). 3. 7:00am Monday morning projectDigestBuild kicks into life. It grabs the digest.xml file (hopefully now containing the weeks appended reports) and does a merge task, merging digest.xml into its own build report. Once merged a python script is executed to delete the Digest.xml file ready to start building a new digest file. 4. Custom XSLT code parses the build logs, if they see 1* <digestEntry/> elements it assumes that this is a digest report and uses the digest rendering code, otherwise it assumes a normal standard build report is being rendered. 5. Emails are generated as required, using the XSLT code in the same way as the web server (step 4). It took a bit or effort to get there... Thanks for all the help guys! Especially Ruben. I hope this serves to help anyone else trying to achieve this same goal. Cheers! Shaun On 22 Jan, 19:34, Ruben Willems <[email protected]> wrote: > Hi > > what you can do to get the variables of a previous build is the following, > in the build script, echo out all the needed parameters, > so you can get them back with xsl. > --> in nant <echo message=${CCNetLabel}"/> > > so the integration properties of the build will be saved in the build log, > > with kind regards > Ruben Willems > > On Thu, Jan 22, 2009 at 5:16 PM, CinnamonDonkey < > > [email protected]> wrote: > > > Another problem with being forced to go the separate project route is > > the fact that the many build varaiables that are being passed to and > > from the external tools are no longer in context for the build that > > you where processing. You are in fact now running a different build in > > a different context with different variables. > > > It would also be impossible to share state information. > > > On 22 Jan, 16:01, CinnamonDonkey <[email protected]> > > wrote: > > > 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 > > ... > > read more »
