Hi Shaun, I don't know if it will help with your scenario, but for the 1.5 release we have added dynamic parameters for a build. These are parameters that a user can set when they are doing a force build, and I'm hoping to expand it into the triggers before the 1.5 release. This would allow you to cut down on the number of projects as you could use parameters instead.
An alternate option that you could use now would be pre-processing, but I don't know as much about this at the moment. Craig -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of CinnamonDonkey Sent: Friday, 23 January 2009 5:17 a.m. To: ccnet-user Subject: [ccnet-user] Re: Weekly Digest Reports 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 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 > > ... > > read more »
