Hi
concerning the dashboard : you can use the category element of a project to group projects together, the dashboard will also show the categories. But the main page will indeed still be cluttered, so maybe add an option to not show the main page? --> so one is forced to use the categories, and filter the results. with kind regards Ruben Willems On Thu, Jan 22, 2009 at 4:03 PM, 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 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 ยป
