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 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 > > ... > > read more »
