Warnings plugin; Can I exclude certain warnings?

[Matthew.Webber]

The Jenkins Warnings plugin (https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin) allows us to select (via a regex) which files we want to analyse. However, I could not see any way to exclude certain warnings we are not interested in. Can this be done?

Use case: We have a large, old code base which has 1400 warnings (cough). A fair number of those are deprecation warnings. I'm started insisting that whenever a developer commits a change to a class, they MUST not introduce any new warnings, and they SHOULD fix up any existing warnings (except Deprecation warnings).

It would help if I could (temporarily) exclude deprecation warnings from the analysis, since they are lower priority.

Matthew


--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[Ulli Hafner]

On 08/24/2012 11:20 AM, [hidden email] wrote:
> The Jenkins Warnings plugin (https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin) allows us to select (via a regex) which files we want to analyse. However, I could not see any way to exclude certain warnings we are not interested in. Can this be done?
>
> Use case: We have a large, old code base which has 1400 warnings (cough). A fair number of those are deprecation warnings. I'm started insisting that whenever a developer commits a change to a class, they MUST not introduce any new warnings, and they SHOULD fix up any existing warnings (except Deprecation warnings).
>
> It would help if I could (temporarily) exclude deprecation warnings from the analysis, since they are lower priority.
>
> Matthew
>
>
This is not possible (in the plug-in) yet.

In order to work in a general way we need to define for each parser a
set of warning type/rule identifiers (like this is done in FindBugs or
Checkstyle). And on the UI part we need the possibility to define the
rules that will be used (or will not).

As a workaround you can either filter/grep the output to a file that is
scanned by the parser. Or you can extend the current parser (or write a
new one) that does the filtering in code. (You can use the UI to define
the new parser)

Ulli

[Matthew.Webber]

Thanks for the comprehensive reply, Ulli.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Ullrich
> Hafner
> Sent: 24 August 2012 15:02
> To: [hidden email]
> Subject: Re: Warnings plugin; Can I exclude certain warnings?
>
> This is not possible (in the plug-in) yet.
>
> In order to work in a general way we need to define for each parser a
> set of warning type/rule identifiers (like this is done in FindBugs or
> Checkstyle). And on the UI part we need the possibility to define the
> rules that will be used (or will not).
>
> As a workaround you can either filter/grep the output to a file that is
> scanned by the parser. Or you can extend the current parser (or write a
> new one) that does the filtering in code. (You can use the UI to define
> the new parser)
>
> Ulli

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[Mark Waite]

Couldn't you also exclude the generation of the deprecation warnings from your compilation command?  If you're using Java as your language, I believe the Sun Java compiler has a way to exclude specific compiler warnings.

Mark Waite

---

From: "[hidden email]" <[hidden email]>
To: [hidden email]
Sent: Friday, August 24, 2012 8:12 AM
Subject: RE: Warnings plugin; Can I exclude certain warnings?

Thanks for the comprehensive reply, Ulli.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Ullrich
> Hafner
> Sent: 24 August 2012 15:02
> To: [hidden email]
> Subject: Re: Warnings plugin; Can I exclude certain warnings?
>
> This is not possible (in the plug-in) yet.
>
> In order to work in a general way we need to define for each parser a
> set of warning type/rule identifiers (like this is done in FindBugs or
> Checkstyle). And on the UI part we need the possibility to define the
> rules that will be used (or will not).
>
> As a workaround you can either filter/grep the output to a file that is
> scanned by the parser. Or you can extend the current parser (or write a
> new one) that does the filtering in code. (You can use the UI to define
> the new parser)
>
> Ulli

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

[Matthew.Webber]

Hi Mark,

That’s not a bad idea, but I still want the deprecation warnings to be available to developers when working in their IDE. For complex reasons, the build system uses the IDE settings for warnings … anyhow, I have a few ideas I can try.

Matthew

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Waite
Sent: 24 August 2012 15:14
To: [hidden email]
Subject: Re: Warnings plugin; Can I exclude certain warnings?

 

Couldn't you also exclude the generation of the deprecation warnings from your compilation command?  If you're using Java as your language, I believe the Sun Java compiler has a way to exclude specific compiler warnings.

 

Mark Waite

 

---

From: "[hidden email]" <[hidden email]>
To: [hidden email]
Sent: Friday, August 24, 2012 8:12 AM
Subject: RE: Warnings plugin; Can I exclude certain warnings?

Thanks for the comprehensive reply, Ulli.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Ullrich
> Hafner
> Sent: 24 August 2012 15:02
> To: [hidden email]
> Subject: Re: Warnings plugin; Can I exclude certain warnings?
>
> This is not possible (in the plug-in) yet.
>
> In order to work in a general way we need to define for each parser a
> set of warning type/rule identifiers (like this is done in FindBugs or
> Checkstyle). And on the UI part we need the possibility to define the
> rules that will be used (or will not).
>
> As a workaround you can either filter/grep the output to a file that is
> scanned by the parser. Or you can extend the current parser (or write a
> new one) that does the filtering in code. (You can use the UI to define
> the new parser)
>
> Ulli

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom