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-cruisecontrolnet/ 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 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. >
