Hi sounds reasonable, let's see what we can come up with ;-)
with kind regards Ruben Willems On Thu, Feb 5, 2009 at 3:04 PM, CinnamonDonkey < [email protected]> wrote: > > 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 >
