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.
