On 26.09.13 20:47 schrieb Ulli Hafner:
> Interested in adding a small explanation in our wiki so that other users will
> find that information more easily?
> https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-email
I have added a sentence to the e
Hi Johannes,
Thanks for sharing your script and letting us know how you got it working!
Geoff
On 26 Sep 2013, at 16:34, Johannes Wienke
wrote:
On 07/10/2013 05:32 PM, Johannes Wienke wrote:
> On 09.07.13 17:16 schrieb Geoff Cummings:
>> Try using something like the following script in the Ema
Thanks Johannes!
Interested in adding a small explanation in our wiki so that other users will
find that information more easily?
https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-email
Ulli
Am 26.09.2013 um 17:34 schrieb Johannes Wienke
:
>
Johannes,
This is a great script, thanks for sharing.
slide
On Thu, Sep 26, 2013 at 8:34 AM, Johannes Wienke <
jwie...@techfak.uni-bielefeld.de> wrote:
> On 07/10/2013 05:32 PM, Johannes Wienke wrote:
> > On 09.07.13 17:16 schrieb Geoff Cummings:
> >> Try using something like the following scr
On 07/10/2013 05:32 PM, Johannes Wienke wrote:
> On 09.07.13 17:16 schrieb Geoff Cummings:
>> Try using something like the following script in the Email Ext script
>> trigger:
>
> Thank you very much. That helped a lot.
To summarize this issue: I have created a trigger script for all
warnings plu
On 09.07.13 17:16 schrieb Geoff Cummings:
> Try using something like the following script in the Email Ext script
> trigger:
Thank you very much. That helped a lot.
Cheers,
Johannes
signature.asc
Description: OpenPGP digital signature
Try using something like the following script in the Email Ext script
trigger:
def violationsList = []
// Add whichever result Actions we are interested in
violationsList.add(build.actions.find{it.class.name =~
"hudson.plugins.checkstyle.CheckStyle.*ResultAction"})
violationsList.add(build.acti
On 09.07.13 14:44 schrieb Ulli Hafner:
> That why I recommend using the *new* warnings (and not the totals). Then you
> find all new warnings regardless of the total number of warnings.
>
> These warnings are shown in the REST report:
> https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+An
That why I recommend using the *new* warnings (and not the totals). Then you
find all new warnings regardless of the total number of warnings.
These warnings are shown in the REST report:
https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plug-ins#StaticCodeAnalysisPlug-ins-remote
You'd have to access the public api directly I believe, not the token or
rest api.
On Jul 8, 2013 10:14 AM, "Johannes Wienke"
wrote:
> On 08.07.13 17:34 schrieb Ulli Hafner:
> > Actually the analysis plugs-in expose the number of new warnings as
> token or via the REST API. Can't you just use tha
On 08.07.13 17:34 schrieb Ulli Hafner:
> Actually the analysis plugs-in expose the number of new warnings as token or
> via the REST API. Can't you just use that information to trigger the email?
That sounds very interesting. Is there any hint on how to access this
information in a trigger script
On 08.07.13 17:01 schrieb Kevin Fleming (BLOOMBERG/ 731 LEXIN):
> I don't think the Warnings plugin exports that information in a way that
> email-ext could extract it at this point, but it's certainly doable.
>
> I'd be quite careful about just using the number of warnings though; a commit
> th
Actually the analysis plugs-in expose the number of new warnings as token or
via the REST API. Can't you just use that information to trigger the email?
Ulli
Am 08.07.2013 um 17:13 schrieb Slide :
> I don't have specific knowledge of the Warnings plugin, so I don't know what
> is available.
>
I don't have specific knowledge of the Warnings plugin, so I don't know
what is available.
On Mon, Jul 8, 2013 at 7:57 AM, Johannes Wienke <
jwie...@techfak.uni-bielefeld.de> wrote:
> Hi,
>
> On 07/08/2013 03:23 PM, Slide wrote:
> > If you used the email-ext plugin, you could add a script trigge
I don't think the Warnings plugin exports that information in a way that
email-ext could extract it at this point, but it's certainly doable.
I'd be quite careful about just using the number of warnings though; a commit
that resolves an existing warning and introduces a new one would be missed,
Hi,
On 07/08/2013 03:23 PM, Slide wrote:
> If you used the email-ext plugin, you could add a script trigger that
> checked for the number of warnings and then sent out an email only if there
> were warnings for that job.
Thanks, that's a solution I didn't know so far.
I know that for something l
If you used the email-ext plugin, you could add a script trigger that
checked for the number of warnings and then sent out an email only if there
were warnings for that job.
slide
On Mon, Jul 8, 2013 at 4:05 AM, Johannes Wienke <
jwie...@techfak.uni-bielefeld.de> wrote:
> Hi,
>
> for our jobs w
Hi,
for our jobs we have several analysis tasks running like PMD, checkstyle
and so on. However, we are currently not in a position that we can
achieve a 0-warnings rate for our projects. Hence failing or marking a
build instable just because of the warnings is no options for use.
However, it woul
18 matches
Mail list logo
