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
