http://jira.public.thoughtworks.org/browse/CCNET-1360
Done! Hi Tim, That sounds like a good solution as a compromise, but personally, as Ruben is already fully aware of. I have issues with being forced to create multiple projects. If like us, you have many products. Turns the dash a right old mess! anyway, that's another thread! cheers, shaun On 5 Feb, 14:16, "Tim Rayment" <[email protected]> wrote: > What about splitting your build into several stages (a build pipeline) where > you have several CruiseControl projects chained together, with each project > doing a specific task. For example Compile, Unit Test, Static Analysis etc. > > You can then tailor the email publisher for each project to target the > appropriate group of developers/testers. > > Here's a link to an > articlehttp://studios.thoughtworks.com/assets/2007/5/11/The-Deployment-Pipel... > Dave-Farley-2007.pdf > > The other benefit you get is that the feedback time is reduced and it's > easier to identify which stage of the build is failing. > > Where I work we have the following pipeline: > 1. Build, unit test and static analysis > 2. Component test > 3. Build installer > 4. Test installer > 5. Integration test > 6. Performance test > > The further you progress down the pipeline, the longer tasks tend to take, > but the greater your confidence that it works as it should. > > Kind regards, > > Tim > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > > Behalf Of CinnamonDonkey > Sent: 05 February 2009 14:05 > To: ccnet-user > Subject: [ccnet-user] Re: Email Publisher: Custome Notification Types > > We feel the need to distinguish between code that compiles > successfully and code that compiles but could have potential flaws. > > Our analysis picks up issues like; potential security exploits, > unreachable code, return values not being checked. These problems do > not justify a build being flagged as failed, it is most likely a > stable and valid version. But the defects need attention to see if > they are genuine issues. > > Surely providing your end-users with the flexibility to adapt the > systems functionality to their own needs is a good thing. > > By providing user defined notification types the end-user can have > finer detail into what actually went wrong with the build. There > company structure may be that they want to report different > notification types to different teams or specific employees. > > We currently have a couple of guys who do all the unit tests... if a > build fails on a unit test we want them to be notified but if the code > fails compilation we want the codes author to be notified. If the code > fails static analysis, we and both the codes author and they're > supervisor to be notified. > > Your product should not be dictating company structure and work flow, > but be flexible to fit into they're requirements. > > I hope this makes sense and does not sound like a complaint or a > digg... it is not. I think you guys are doing a great job!!! > > I'll make a change request up ;-). > > Regards, > Shaun > > On 5 Feb, 12:31, Ruben Willems <[email protected]> wrote: > > Hi > > > you surely can add it to the change request pool (JIRA) > > but why another notification type? > > > if it needs fixing : break the build > > if it does not need fixing : do not bother the programmer > > > Am I missing something? > > > In my setup, I have something similar, > > during the CI integration, some warnings may be ok. > > > But when the button is pressed: 'ProjectXToQA', there may be NO warnings > > > with kind regards > > Ruben Willems > > > On Thu, Feb 5, 2009 at 1:25 PM, CinnamonDonkey < > > > [email protected]> wrote: > > > > Hi All (Read as DevTeam ;), > > > > I have now set-up our incremental build process. The main purpose of > > > which is to run static code analysis on every change list submitted. > > > This analysis generates a build report which lists any code defects > > > detected and notifies the change list owner so that they can fix > > > their defects. > > > > The problem I have thougth is a build with defects is NOT a failed > > > build. The build is most likely successful. This means that currently > > > we must spam the user with emails for every build with and without > > > defects. > > > > Off course this means that sooner or later the end-users will start to > > > ignore their emails and will miss defects that need fixing. > > > > What would be handy is if we could define our own notification types. > > > This way I could create a notification type called "DEFECTS" and setup > > > the users to be emailed in the event of defects being detected in > > > their code. > > > > Is there currently a way of doing this? Is this something that could > > > be added to the change requests for post 1.4.3? > > > > Regards, > > > Shaun
