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 project. > > > > > > > You can also use the modification writer task, to write all the > > > > > modifications per project. > > >http://confluence.public.thoughtworks.org/display/CCNET/Modification+. > .. > > > > > > > So now you should have the metrics and the modifications. > > > > > Ok they are per project and stored in different files, but you get > them > > > > > automatically. > > > > > > > Now for trigering : > > > > > you can add a ccnet project for this 'Make Week Reports', that is > > > sheduled > > > > > to run at monday 06:00 (schedule trigger) > > > > > this will run a program that creates the reports. Making it run > after > > > the > > > > > last checkin, is not possible in my opinion. > > > > > Define 'last build' ;-) > > > > > > > So I would suggest that it will run at 06:00, and the managers can > have > > > it > > > > > at 06:05 am, normally managers like this kind of stuf ;-) > > > > > > > now you must write a program that makes the report of these files. > > > > > Should not be that hard. > > > > > > > with kind regards > > > > > Ruben Willems > > > > > > > On Mon, Jan 19, 2009 at 10:46 AM, CinnamonDonkey < > > > > > > > [email protected]> wrote: > > > > > > > > Hi All, > > > > > > > > I have been asked to configure CC.Net to generate weekly digest > > > > > > reports of the installations activity. This report should have a > > > > > > format something like this: > > > > > > > > Header. > > > > > > Summary of weeks builds (Data, Time, Change List Used, Outcome, > > > > > > Defect Metrics for the week). > > > > > > Detailed Report per build for the week (Date, Time, Change List > > > > > > Used, Outcome, Modifications, Test Results). > > > > > > > > My Team Lead seems to be very keen on this feature, suggesting > that > > > > > > all team leads should receive this weekly digest report so that > they > > > > > > can keep track of the project status and the staff working on the > > > > > > project. > > > > > > > > To be honest though, I can't for the life of me think where to > begin > > > > > > to provide this functionality within the scope of what CC.Net > > > > > > provides. > > > > > > > > The only why I can think to do this is to collate all the metrics > > > > > > myself and run a Python script to parse the results once a week. > > > > > > > > This leads to another problem... how to trigger the event which > needs > > > > > > to occur after the last build of the week. > > > > > > > > Any ideas? > > > > > > > > Cheers, > > > > > > Shaun. >
