Skip to end of metadata
Go to start of metadata

Plugin Information

View Warnings on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin generates the trend report for compiler warnings in the console log or in log files.

Installation Requirements

This plug-in requires the utility plug-in "analysis-core" (called "Static Analysis Utilities" in the update manager). Please ensure that the latest version of this plug-in is also installed.


(lightbulb) This plug-in is supported by the Static Analysis Collector plug-in that collects different analysis results and shows the results in aggregated trend graphs. Additionally, health reporting and build stability is also based on the aggregated results.

You need to add the post-build action scan for compiler warnings to actually get warnings. (By default none will be generated.) 

Select one or more parsers corresponding to the warnings you want to get. Each parser will generate a specific warning. Parser javac generates Java Warnings. The Maven parser generates Maven Warnings. Etc... 

The Warnings plug-in scans the console log or specified log files for warnings of different formats and reports the number of warnings found. This plug-in is part of the suite of static code analysis plug-ins that are documented on a separate WIKI page.

  • Support for javac (ant, maven, command line), Eclipse Java Compiler, JavaDoc Compiler, Hudson/Jenkins HPI, MSBuild, GCC, GNU Linker, SUN Studio C++, Gnat (Ada), Erlang, PC-Lint compiler warnings (configuration of PcLint), Eclipse Buckminster, Oracle Invalids, Doxygen, Robocopy, Perforce, Cobol, PHP, Flex, YUI Compressor, puppet-lint, FxCop, C++ lint, CSSLint, JCReport, JSLint, Pep8, PYLint, StyleCop, IBM XL C/C++ Compiler and Linker, NAG Fortran Compiler, GNU Fortran Compiler, Resharper Commandline Tools, Microsoft PREfast, Imported from the violations plug-in: Codenarc, Gendarme
  • Build summary showing the new and fixed warnings of a build
  • Several trend reports showing the number of warnings per build
  • Overview of the found warnings per module, package, category, or type
    • Parsing of Maven pom.xml or Ant build.xml configuration files to obtain the module or project name
    • Parsing of Java or C# files to obtain the package or name space name
  • Detail reports of the found warnings optionally filtered by severity (or new and fixed)
  • Colored HTML display of the corresponding source file and warning lines:
    • Direct link to the warning line
    • Highlighting of single lines as well as line ranges
    • Highlighting of multiple line ranges per warning (different color for primary range)
    • Tool tip describing the warning message
  • Failure threshold to mark a build as unstable
  • Configurable project health support
  • Works with the freestyle and native m2 build option (activated on goal compile)
  • Remote API to export the build quality and found warnings
  • Several tokens to simplify post processing of the results
  • Localization available for: DE, JA (Please help to localize findbugs for your locale!)

The current release is available in the download section. This plug-in is developed and maintained by Ullrich Hafner. Please use the mailing lists or issue tracker to ask questions, create feature request or bug reports, since I don't read the comment section on this page regularly.

Adding support for new warning types

If there is a parser missing, then you can simply extend the available set of parsers using one of the following methods.

Defining a new parser using the user interface

Since release 3.8 you can define new parsers dynamically in the system configuration section of Jenkins. Just navigate to http://\[jenkins-url\]/configure and create a new parser in section Compiler Warnings. The UI should be self explanatory, if there is something missing, please let me know on the mailing lists.

Writing a new parser that should be included in the warnings plug-in

Extending the existing set of supported warning formats is quite easy. If the format of the warnings messages could be parsed by an regular expression, then you only need to provide a new parser class and a corresponding test case:

  1. Set up your developing environment as described in the Plugin tutorial
  2. Clone the warnings plug-in from GitHub
  3. Run maven with the command mvn install to see if the plug-in builds before you change anything
  4. Add a new class YourFormatParser to the package hudson.plugins.warnings, see GccParser or JavacParser as examples
  5. Add a new test case YourFormatParserTest to the package hudson.plugins.warnings, see GccParserTest or JavacParserTest as examples.
  6. Note that the parser is automatically registered using the @Extension annotation
  7. Send a pull request to get your changes integrated

Writing a new standalone parser that will be deployed in a new plug-in

If your parser is only of interest for your team or company then you can also develop a parser that will be bundled into a separate and private plug-in. The development approach is quite similar:

  1. Set up your developing environment as described in the Plugin tutorial
  2. Create a new plug-in that depends on the latest release of the warnings plug-in
  3. Add a new parser class that implements WarningsParser. If your parser is based on regular expressions, then consider extending from either RegexpDocumentParser (multi-line parser) or RegexpLineParser (single-line parser).
  4. Annotate your class with @Extension
  5. Package your plug-in and deploy it to your Jenkins instance


Release 4.65

Release 4.64

Release 4.63

  • Compute author and commit information using the Git blame command. Show report of warnings by user on the job page and in the dashboard view. ( JENKINS-6748 - Analysis of Checkstyle Warnings per User RESOLVED )
  • Removed script checking with script security plugin, now a simple permission check makes editing of Groovy scripts secure ( JENKINS-43813 - Getting issue details... STATUS )
  • Added option to filter for categories (thanks to jpfeuffer for the pull request)
  • Make java parser be compatible with Kotlin compiler (thanks to Sean Flanigan for the pull request
  • Improved IAR parser (thanks to Kay van der Zander vor the pull request)

Release 4.62

  • Added a new symbol for pipelines: warnings
  • Added parser for Robot Framework Lint (thanks to Traitanit Huangsri for the pull request)

Release 4.61

Release 4.60

  • Improved performance of MS Build parser (thanks for Emil Styrke for the PR for JENKINS-42221)
  • Removed false positives for MS Build parser (JENKINS-36817)
  • Expose Groovy parser configuration for scripts (thanks to Thierry Lacour for the PR)

Release 4.59

  • Show the parent page if user selects an invalid URL (JENKINS-37195)
  • Don't use an empty category or type anymore when displaying the warning aggregations (JENKINS-38557)
  • Detect MSBuild command line warnings (JENKINS-38215)
  • Detect JavaDoc errors in 1.8 format (JENKINS-37975)
  • Do not access the workspace in pipelines (JENKINS-39532).

Release 4.58

Release 4.57

  • Added new parser for Ansible Lint (Thanks to Ce Qi for the pull request)
  • Added new parser for Sphinx-build (Thanks to Robert Williams for the pull request)

Release 4.56

  • Fixed deactivation of trend graphs (using the analysis collector plug-in)

Release 4.55

  • Prevent false positives: Let JavaDoc parser scan only lines containing the text javadoc (JENKINS-32298)

Release 4.54

  • Added new parsers for QAC, Metrowerks CodeWarrior (linker and compiler), Tasking VX compiler, EB tresos Studio (thanks to Sven Lübke for the PRs)
  • Reduced priorities of pep8 parser (JENKINS-32295)
  • Fixed false positive (JENKINS-34141)
  • Update of JavaDoc parser for Java 8 (JENKINS-32298)
  • Update of GnuMakeGccParser to match current version (thanks to Norbert Lange for the PR)
  • Fixed missing dependency to joda-time (JENKINS-17062)
  • Expand environment variables in file pattern (JENKINS-30735)
  • Validate pattern using the ant pattern validator (JENKINS-34760)
  • Immediately change the trend graph after configuration (JENKINS-22295)

Release 4.53

  • Added support for version 5 of the ARMCC compiler (Thanks to Dmytro Kutianskyi for the pull request)
  • Improved performance of the Eclipse Java parser (JENKINS-27664: Thanks to Tobias Gruetzmacher for the pull request)

Release 4.52

  • Don't alter SAX environment variable anymore (JENKINS-27548)
  • Fixed resolving of files with relative paths in workspace (JENKINS-32150)

Release 4.51

  • Improved several parsers (thanks for the pull requests)
  • Make maven plug-in mandatory since otherwise class loading exceptions will sometimes destroy the build configuration (JENKINS-21268, JENKINS-14727)

Release 4.50

  • Fixed broken configuration of include/exclude patterns (JENKINS-30329)

Release 4.49

  • Added support for workflow plug-in (Thanks to Antonio Muñiz and Manuel Recena for their PRs)
  • Fixed links in detail page of trend reports (JENKINS-29900)

Release 4.48

  • Improved computation of new and fixed warnings: now the state of a warning (old, new, fixed) is persisted (JENKINS-24940)
  • Improved several parsers: PyLint, PuppetLint, ScalaStyle, MSBuild, IntelliJ, Resharper (thanks for the pull requests!)

Release 4.47

  • Fixed aggregation action for matrix builds

Release 4.46

Release 4.45

  • Reverted XML escaping of messages (JENKINS-25511, JENKINS-17309)
  • Added option to use previous build as reference build when calculating new and fixed warnings (JENKINS-13458, thanks to Tom Saunders for the pull request)
  • Added parser for AspectJ (thanks to Tom Diamond for the pull request)

Release 4.44

  • Improved speed of Maven parser (thanks to Adrien Lecharpentier for the pull request)
  • Fixed threshold evaluation to set a build to unstable or failed (JENKINS-25501)

Release 4.42

  • Added new parser for Scala compiler warnings (thanks to Alexey Kislin for the pull request)
  • Added support Visual Studio 2013 CodeAnalysis format (thanks to Rafał Jasica for the pull request)
  • Apply include/exclude filters after absolute path expansion (JENKINS-24011)
  • Use default encoding when reading the console log (JENKINS-24611)
  • Fixed warnings column in matrix projects (JENKINS-23446)

Release 4.41 - new runtime requirement: at least Java 6

  • Improved PHP parser (thanks to Greg for the pull request)
  • Improved Puppet Lint parser (thanks to Jon Skarpeteig for the pull request)
  • Fixed Resharper name (thanks to Chris for the pull request)
  • Added IntelliJ IDEA parser (thanks to Alex Lopashev for the pull request)
  • Removed leading slash from image UR (JENKINS-23677)
  • Fixed encoding problems with messages using cyrillic alphabet (JENKINS-22744)

Release 4.40

  • Added support for PREfast Visual Studio Tools (thanks to Charles Chan for the pull request)
  • Fixed validation of Groovy parsers when lineNumber property is used (JENKINS-21569)

Release 4.39

  • Added support for Resharper commandline tools (JENKINS-21596, thanks to Rafał Jasica for the pull request)
  • Expose the current line number in Groovy parsers (JENKINS-21569)
  • Added support for tycho 0.19.0 (JENKINS-21377, thanks to Uwe Petschke for the pull request)
  • Improved Java parser to parse annotation warnings (JENKINS-21240)
  • Fixed icon URLs (JENKINS-21510)

Release 4.38

  • Fixed serialization of GNU Make and C Compiler warnings (JENKINS-20558)

Release 4.37

Release 4.36

  • Added new parser for GNU Fortran compiler (thanks to Mat Cross for the pull request)
  • Improved naming of several C compilers (thanks to Mat Cross for the pull request)
  • Improved regular expression of MS Build parser to catch Visual studio messages (JENKINS-19425)

Release 4.35

  • Added a view column that shows the number of warnings in a job
  • Fixed broken trend graph in dashboard (JENKINS-19425)

Release 4.33

  • Show affected console log when selecting a maven warning

Release 4.32

  • Make dependency to ant-plugin optional (JENKINS-17496)
  • Added support for JSLint warnings in Checkstyle format (JENKINS-19127)
  • Extract column number from warnings where available
  • Improved IAR parser

Release 4.28

  • Don't show trend and health reports of aggregated warnings (JENKINS-18852)
  • Fixed handling of localized warning messages in Doxygen parser (JENKINS-18913, thanks to Olaf Mandel for the pull request)
  • Fix sorting of warnings that are on same line but different column (JENKINS-19047)
  • Show results of threshold evaluation also in console log (JENKINS-18954)
  • Escape XML symbols in warning messages (JENKINS-17309)

Release 4.27

  • Implemented new parsers for Perl::Critic, JCReport, CSSLinit, PyLint, Pep8, StyleCop based on the existing violations plug-in parser that now work in slave builds (JENKINS-17786, thanks to Mihail Menev, Johann Vierthaler, Sebastian Seidl, Sebastian Hansbauer, Marvin Schütz for the patches!)
  • Added a new parser for NAG Fortran Compiler (thanks to Mat Cross for the patch!)
  • Added support for fatal errors in Wind River Diab Compiler (C/C++) parser (JENKINS-17075, thanks to Sebastian Seidl for the patch!)
  • Improved regular expression of IAR parser for EWarm 6.3 compiler
  • Improved regular expression of Cpp-Lint parser (JENKINS-18290)
  • Fixed NPE when a parser of the violations plug-in is used (JENKINS-15492 thanks to benny-shotvibe for the patch!)
  • Added aggregated result that are exposed via the REST URL warningsResult (JENKINS-17767, thanks to Sebastian Hansbauer, Marvin Schütz for the patch!)
  • Added some more fields that are exposed via the REST API (JENKINS-17767, thanks to Mihail Menev, Johann Vierthaler for the patch!)
  • Added Traditional Chinese translations (thanks to Pei-Tang Huang!)
  • Added system configuration option to disable console logging of all static analysis plug-ins (JENKINS-15246, thanks to Sebastian Seidl for the patch!)
  • Added system configuration option to fail a build when one of the static analysis plug-ins fails parsing its input (JENKINS-17663, thanks to Mihail Menev and Johann Vierthaler for the patch)
  • Fixed broken encoding handling in maven jobs (JENKINS-17657, thanks to André Lehmann!)

Release 4.26

  • Added three new parsers from the violations plug-in: Perl::Critic, StyleCop, PyLint (JENKINS-17911)
  • Fixed parser matching problems after name change of CLANG parser (JENKINS-17762)

Release 4.25

Release 4.23

  • Show more details in the fixed warnings view (JENKINS-15959)
  • Aggregate the maven parent module results in failed builds when the failure is caused by a threshold being hit (JENKINS-15324, JENKINS-12342)
  • Optimized http requests for static resources in the analysis plugins (JENKINS-16571)
  • Fixed missing build overview in maven jobs (JENKINS-16518)
  • Always use Xerces when parsing XML files (JENKINS-15613)
  • Read pom.xml to obtain path of output files in maven jobs (JENKINS-16250)
  • Show error message as file content if the source files could not be transferred to the master (JENKINS-16222)
  • Improved performance of dynamic parsers (Thanks to Jesse Glick for the patch, JENKINS-16526, JENKINS-16107)
  • Do not show blank Maven warnings (JENKINS-16826)

Release 4.21

  • Improved plug-in performance when dynamic groovy parsers are used (JENKINS-16526, JENKINS-16107, thanks to Jesse Glick for the patch)

Release 4.20

  • Added a new parser for IBM XLC Compiler and Linker (thanks to Andrew Gvozdev for the pull request)

Release 4.19

Release 4.18

Release 4.17

  • Fixed wrong computation of new and fixed warnings (JENKINS-14821)

Release 4.16

Release 4.15

  • Make dependency to maven plug-in optional (JENKINS-14727)
  • Improved performance if several dynamic parsers are defined (JENKINS-14614)

Release 4.14

Release 4.13

Release 4.12

  • Fixed problems when Apple LLVM compiler is used with make (JENKINS-14333)
  • Added new parser for GCC that detects the correct paths using debug messages of GNU make (thanks to Victor Hakoun)

Release 4.11

Release 4.10

  • Fixed NPE during de-serialization of 3.x configuration files (JENKINS-14281)

Release 4.9

Release 4.7

  • Reduce memory footprint of plug-in (thanks to Kohsuke for the patches)
  • Upgrade to YUI 2.9 (support for new bread crumbs and context menus: JENKINS-13532, thanks to OHTAKE Tomohiro for the patch)
  • Added option to suppress the automatic but time expensive resolution of relative path names (JENKINS-14024)
  • Added support for Eclipse 3.8/4.2 compiler messages (JENKINS-13969)
  • Added native parser for C++ Lint (JENKINS-14018)

Release 4.6

Release 4.5

  • Added hyperlinks to build summary if threshold is exceeded (JENKINS-12424)
  • Added parser for Apple LLVM compiler (thanks to Neil Davis for adding this parser)
  • Fixed trend graph showing the values of wrong parser (JENKINS-13656)

Release 4.4

  • Added option to filter projects with zero warnings in the warnings dashboard portlet (JENKINS-12984)
  • Center the affected source line in source view (JENKINS-13491)
  • Fixed incompatibility of detail tabs with new bread crumb view (JENKINS-13532)
  • Fixed history of warnings using the Eclipse Parser (JENKINS-13573)
  • Fixed missing JavaDoc parser (JENKINS-13610)
  • Added new parser for Wind river Diab C++ warnings (thanks to Yuta Namiki for the patch)
  • Improved IAR Parsers (thanks to Johan Holmberg of IAR for the valuable help): please use option --no_wrap_diagnostics when running the compiler

Release 4.3

  • Fixed deserialization of warnings trend graph portlet

Release 4.0

  • Added a new portlet that shows the warning totals as a line graph
  • Results are now shown separately for each parser (JENKINS-10319): i.e., links, trend graphs, result summary, detail pages, etc. are shown for each active parser. Even images are customizable, so if you would like to change the default image for your favorite parser please send me a corresponding image. You can have a look at the Java parser for an example.
  • Added new parser for Maven Console warnings
  • Added parsers of the violations plug-in (if the violations plug-in is installed):
    • Codenarc
    • CppLint
    • CSSLint
    • FxCop
    • Gendarme
    • JCReport
    • JSLint
    • Pep8
    • PYLint
    • StyleCop

Release 3.28

Release 3.27

  • Added support for puppet-lint (pull request by Jan Vansteenkiste)
  • Improved YUI Compressor parser (patch by Emidio Stani)
  • Fixed slave parsing with dynamic (Groovy script) or custom (extension point) parsers (JENKINS-12280, JENKINS-11926)

Release 3.26

  • Fixed initialization problem when configuring the warnings plug-in. (JENKINS-12075)

Release 3.25

  • Fixed NPE while configuring a graph with no builds yet (JENKINS-12045)
  • Group warnings by relative path if the associated language has no package or namespace concept (JENKINS-11846)
  • Allow skipping of calculating "new" issues (JENKINS-11761)
  • Fixed display of 'Use delta for new warnings' option (JENKINS-11758)
  • Ignore 'new warnings' threshold in the first build (JENKINS-11718)
  • Ignore console annotations when scanning for warnings (JENKINS-11675)
  • Stop parsing immediately if user presses cancel (JENKINS-11792)
  • Added support for Armcc warnings (Thanks to Emanuele Zattin for this patch)

Release 3.24

  • Improved performance of console annotation filtering (JENKINS-11675)

Release 3.23

  • Fixed parsing of file names if console log is decorated with notes (JENKINS-11675)

Release 3.22

  • Added parser for YUI Compressor (JENKINS-4502)
  • Fixed enlarge link for trend graphs (JENKINS-11324)
  • Fixed visibility of 'enable trend graph' link
  • Fixed reading of results if analysis is invoked during 'mvn site' (JENKINS-10820)

Release 3.21

  • Ignore failed builds when evaluating the build history in trend graphs and new warnings calculation (JENKINS-10682)
  • Added OSGi bundle detection when grouping warnings by module (JENKINS-10681)
  • Use the path as a replacement for the package grouping for all warnings that are not from Java or C# files (issue 2)
  • Cancel parsing if the build has been aborted by the current user (JENKINS-10627, JENKINS-9158)
  • Start from workspace root when scanning for warnings in m2 projects (JENKINS-10332)
  • Improved MS Build warnings (JENKINS-10566)

Release 3.20

  • Fixed broken file names if the warning message is prefixed by an ant goal (JENKINS-9926)

Release 3.19

  • Added option to specify different parsers for console log and for workspace files (JENKINS-8833)
  • Added new tokens for token macro plug-in (JENKINS-10027): now tokens WARNINGS_NEW, WARNINGS_FIXED, WARNINGS_COUNT and WARNINGS_RESULT are available.

Release 3.18

  • Added new trend graph that shows the total number of warnings with auto-scaled range axis (JENKINS-9745)
  • Added persistence for example field when configuring a Groovy parser (JENKINS-9535)
  • Fixed broken result images in build summary (JENKINS-9997)

Release 3.17

  • Added new extension point to simplify creation of project or tool specific parsers
  • Fixed broken detail views when using a reverse proxy (JENKINS-3410, thanks to Benjamin Cabé for the fix)
  • Show the reference build that is used to compute new and fixed warnings (when build thresholds are set)
  • Improved logging statements when build is executed on a slave

Release 3.16

  • Added configuration option to enable automatic project and module name detection by reading all Ant project.xml and Maven pom.xml files (JENKINS-8915, JENKINS-9090)
  • Added preliminary support for the Token Macro Plugin: WARNINGS_COUNT expands to the number of warnings and WARNINGS_RESULT expands to the plug-in build result (stable, unstable, failed)

Release 3.15

  • Fixed missing dependency to Hudson/Jenkins 1.395 (JENKINS-8509)

Release 3.14

  • Jenkins update to links and documentation
  • Show progress text while dashboard portlet graphs are created

Release 3.13

Release 3.12

  • Added support for multi-configuration projects (JENKINS-6772)Release 3.12
  • Added support for multi-line warning messages in user definable parsers (JENKINS-8399)
  • Improved MS Build parser to also handle Stylecop warnings (JENKINS-8347)
  • Improved JavaDoc parser (JENKINS-7718)
  • Fixed sorting of date labels of dashboard trend graphs (JENKINS-8476)
  • Fixed evaluation of builds that will be considered in the dashboard trend graph (JENKINS-8283)
  • Fixed warnings totals counter (JENKINS-7775)

Release 3.11

  • Added new parser for GHS Multi compiler warnings (thanks to Joseph Boulos for the patch)
  • Added build status thresholds for each warning priority (JENKINS-3561)
  • Fixed parsing of file names if console log is decorated with notes (JENKINS-7417)
  • Fixed parsing of tycho Eclipse Java compiler warnings (JENKINS-4996)

Release 3.10

Release 3.9

Release 3.8

  • Added a new generic parser that can be configured in the UI to enable parsing of project specific warning messages without the need of extending the plug-in (JENKINS-3895).
  • Fixed ant links (JENKINS-6862)
  • Fixed parsing of multi-core build with MS Build (JENKINS-6709)
  • Fixed parsing of doxygen 1.7.1 messages (JENKINS-6971)
  • Fixed computation of module names for maven projects (JENKINS-6768)
  • Don't report an error message if a maven module does not contain a report file (JENKINS-6895)

Release 3.7

  • Fixed naming of maven modules (JENKINS-6513)
  • Group files by path if there is no package or namespace found (JENKINS-6698)

Release 3.6

Release 3.5

  • Added trend graph portlets for the dashboard view
  • Added option to start the plug-in even for failed builds (JENKINS-6117)
  • Added 'enlarge' link for trend graphs that shows a detail page with the graph
  • Fixed ordering of warnings in detail views (JENKINS-6132)
  • Fixed warning distribution graph in files detail view (JENKINS-6139)

Release 3.4

Release 3.3

  • Added parser for PHP warnings (thanks to Shimi Kiviti for the patch)
  • Added parser for Flex SDK warnings (thanks to Vivien Tintillier for the patch)
  • New warnings computation is now based on the current build and the reference build (i.e., the last successful build, see JENKINS-5147)
  • Visualized plug-in build status (based on the healthiness thresholds)
  • Added high scores for successful builds
  • Improved warnings detection for the Intel C++ compiler 11.1 (JENKINS-5402)
  • Fixed handling of arrays in warning messages (JENKINS-5868)
  • Don't show project action if there are no warnings (JENKINS-5473)
  • Don't show trend graph configuration on job creation (JENKINS-5294)
  • Improved remote API, now the warning keys are also exposed (JENKINS-5195)

Release 3.2

Release 3.1

  • Added parser for AcuCobol warning messages (JENKINS-5024, thanks to Jerry Shea for the patch)
  • Improved MSBuild parser to also display sharepoint warnings (JENKINS-4731)
  • Fixed regular expression for GCC parser (JENKINS-4707)
  • Fixed trend report link if there are no results available yet (JENKINS-5156)
  • Fixed preview of trend reports
  • Added dependency to Hudson 1.337 due to a class loader bug in previous versions (JENKINS-4993)

Release 3.0

  • Extracted common code of the static code analysis plug-ins into a new utility plug-in "analysis-core"
  • Several bug fixes and small improvements

Release 1.x-2.x Changelog


  1. Unknown User (fr4ncois)


    How could I use this plug-in with Matrix Jobs? Because when building a matrix job, builder output are not visible in the main log while the plug-in only parse this main log.


    1. This is not supported yet, see JENKINS-6772.

  2. Is it possible in the groovy script to reference build-specific or job-specific variables? I specifically would like to be able to have access to the workspace directory variable

  3. Is there a way to disable certain types of warning parsers?  I'm working with a Java centric project but for some reason I get gcc4 warnings.  The gcc4 warnings that are reported are the same as the Java warnings but they have the string "[java] " pre-pended.

    1. You can select the parsers in the job configuration screen.

  4. Hoi Ulli

    Latest ChangeLog entry is wrong - should read "Release 3.16", not "Release 4.15". You just have too many related jenkins plugins ;-)

    Gruäss - stefan.

    1. Just discovered that I actually have edit rights on this page --> fixed.

      1. Servus Stefan(smile) Thanks for fixing...

  5. Hello

    Is it possible to give one log build as reference build for warning ? In fact I dont want to refer only to the last build but for a given build done at given time.

    1. The reference build is computed automatically.

  6. Hi Ulli,

    Received following errors that broke the build:WARNINGS MSBuild : Found 1 warnings.
    ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception
    java.util.NoSuchElementException: No reference build found for MY_Earlysail_Webservice #8
    at hudson.plugins.analysis.core.BuildHistory.getReferenceBuild(
    at hudson.plugins.analysis.core.BuildHistory.hasReferenceBuild(
    at hudson.plugins.analysis.core.BuildResult.initialize(
    at hudson.plugins.analysis.core.BuildResult.<init>(
    at hudson.plugins.warnings.WarningsResult.<init>(
    at hudson.plugins.warnings.WarningsPublisher.perform(
    at hudson.plugins.analysis.core.HealthAwarePublisher.perform(
    at hudson.tasks.BuildStepMonitor$2.perform(
    at hudson.model.AbstractBuild$AbstractRunner.perform(
    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    at hudson.model.Build$RunnerImpl.post2(
    at hudson.model.AbstractBuild$
    at hudson.model.ResourceController.execute(

    Is there any way to resolve this? Thanks

  7. Hi Ulli,

    I've been using the plugin a couple of weeks now for our new ci setup for our C++ code. First let me say I'm really happy with your plugin. However since the last update of the plugin we're getting the following problems when the plugin finds warnings.

    [WARNINGS] Parsing warnings in console log with parsers [Doxygen, GNU compiler (gcc), GNU compiler 4 (gcc)]

    [WARNINGS] Doxygen : Found 12 warnings.

    [WARNINGS] GNU compiler (gcc) : Found 12 warnings.

    [WARNINGS] GNU compiler 4 (gcc) : Found 12 warnings.

    ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception

    hudson.util.IOException2: remote file operation failed: c:\jenkins_workspaces\workspace\SensCppXp32bitDebugBuild at hudson.remoting.Channel@1377d92:

    at hudson.FilePath.act(

    at hudson.FilePath.act(

    at hudson.plugins.warnings.WarningsPublisher.perform(

    at hudson.plugins.analysis.core.HealthAwarePublisher.perform(

    at hudson.tasks.BuildStepMonitor$2.perform(

    at hudson.model.AbstractBuild$AbstractRunner.perform(

    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(

    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(

    at hudson.model.Build$RunnerImpl.post2(

    at hudson.model.AbstractBuild$



    at hudson.model.ResourceController.execute(


    Caused by: Remote call on failed


    at hudson.FilePath.act(

    ... 13 more

    Caused by: java.lang.ClassNotFoundException: Failed to deserialize the Callable object. Perhaps you needed to implement DelegatingCallable?

    at hudson.remoting.UserRequest.perform(

    at hudson.remoting.UserRequest.perform(

    at hudson.remoting.Request$

    at java.util.concurrent.Executors$ Source)

    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

    at Source)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

    at java.util.concurrent.ThreadPoolExecutor$ Source)

    at hudson.remoting.Engine$1$

    at Source)

    Caused by: java.lang.ClassNotFoundException: hudson.plugins.warnings.parser.Warning

    at$ Source)

    at Method)

    at Source)

    at java.lang.ClassLoader.loadClass(Unknown Source)

    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)

    at java.lang.ClassLoader.loadClass(Unknown Source)

    at java.lang.Class.forName0(Native Method)

    at java.lang.Class.forName(Unknown Source)

    at Source)

    at hudson.remoting.ObjectInputStreamEx.resolveClass(

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at java.util.HashSet.readObject(Unknown Source)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at Source)

    at hudson.remoting.UserRequest.deserialize(

    at hudson.remoting.UserRequest.perform(

    ... 9 more

    This happens when building on a slave node. We're using the latest version of jenkins 1.421, the latest warnings 3.19 and the latest static analysis utilities 1.24.

    Is there any way to resolve this?

    Thanks in advance for any help.

    1. This typically is a problem with an outdated version of your slave.jar file on your slave. Can you please upgrade to the latest Jenkins version for that file?

      1. I updated the slave.jar and it works perfectly again. Thanks a lot for the help. Next time I'll check the slave.jar version first.

      2. In Jenkins 1.423 using 3.20 of the Warnings plugin, we started getting a similar message.  We checked the slave.jar and found it was up to date.  After checking our project configuration, we found that we had not selected a parser.  In builds that used previous versions of the plugin, we received "[WARNINGS] Warning: List of parsers is empty. It is recommended to select at least one parser".  It looks like as of version 3.19, this check has been made more strict.  Selecting a parser fixed the error.

  8. Very useful plugin. Thanks a lot.

    Unfortunatelly I found an issue which does not preview the code that produced the warning when clicking on the filename for a warning message. instead the following content appears:

    Content of file file.c

    01 Copying the source file '../../path/to/file.c' from the workspace to the build folder '######' on the Hudson master failed.
    02 Seems that the path is relative, however an absolute path is required when copying the sources.
    03 Is the file 'file.c' contained more than once in your workspace?
    04 Is the file '../../path/to/file.c' a valid filename?
    05 If you are building on a slave: please check if the file is accessible under '$HUDSON_HOME/job-name/../../path/to/file.c'
    06 If you are building on the master: please check if the file is accessible under '$HUDSON_HOME/job-name/workspace/../../path/to/file.c'
    07 hudson.util.IOException2: remote file operation failed:../../path/to/ hudson.remoting.Channel@12f4538:######
    08   at hudson.FilePath.act(
    09   at hudson.FilePath.act(
    10   at hudson.FilePath.copyTo(
    11   at hudson.plugins.analysis.core.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(
    12   at hudson.plugins.analysis.core.HealthAwarePublisher.perform(
    13   at hudson.tasks.BuildStepMonitor$2.perform(
    14   at hudson.model.AbstractBuild$AbstractRunner.perform(
    15   at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    16   at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    17   at hudson.model.Build$RunnerImpl.post2(
    18   at hudson.model.AbstractBuild$
    19   at
    20   at
    21   at hudson.model.ResourceController.execute(
    22   at
    23 Caused by:  ../../path/to/file.c(No such file or directory)
    24   at Method)
    25   at<init>(
    26   at hudson.FilePath$30.invoke(
    27   at hudson.FilePath$30.invoke(
    28   at hudson.FilePath$
    29   at hudson.remoting.UserRequest.perform(
    30   at hudson.remoting.UserRequest.perform(
    31   at hudson.remoting.Request$
    32   at java.util.concurrent.Executors$
    33   at java.util.concurrent.FutureTask$Sync.innerRun(
    34   at
    35   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    36   at java.util.concurrent.ThreadPoolExecutor$
    37   at

    Obviously, the plugin doesn't like relative path names. Do you have idea how this can be managed? It's not trivial because the compiler output depends on the used build system.

    I am also working on an extension to support the ARM compiler. Could this also be added once I completed it?

    Best regards,


    1. I think there is already an issue for this problem. I think the code to find duplicate files (based on relative names) needs to be smarter.

      New parsers are always welcome!

  9. Hi, thanks for this plugin, it is very useful.

    There is something I do not understand.  My Jenkins job does incremental builds.  Therefore, if a few files are compiled and generate warnings the warnings trend goes non-zero, but if different files are compiled on the next run, and no new warnings are found, the warnings trend goes back to zero, even though the original warnings are not fixed. 

    i.e. warnings are not accumulated.

    Is there a way around this please?

    1. This in not possible at the moment. The plug-in delta computation requires a full build.

  10. I am running Warnings plugin 3.21.  The console output of my job reports:

    [WARNINGS] Parsing warnings in console log with parsers [GNU compiler 4 (gcc), GNU compiler 4 (ld)]

    [WARNINGS] GNU compiler 4 (gcc) : Found 265 warnings.

    [WARNINGS] GNU compiler 4 (ld) : Found 0 warnings.

    But the 'Compiler warnings' screen for the job reports only 67 warnings.

    Why is there a difference?

    1. Duplicate warnings are suppressed in the UI and reports. Can you provide some examples in a Jira bug report?

  11. Several people have wondered about including information from the Warnings plugin into their emails. With email-ext this should be possible, but I can't seem to figure out how to get at the actual data for the warnings information that is so nicely displayed on the build page. Any tips?

    1. I haven't yet used the email ext plug-in. What is the starting point of such an expression? I don't find an example on the wiki page...

      Most of the information is already visible via the remote API:

  12. I've noticed with a newest version of the Warnings plugin (I probably skipped a few so can't say when it changed exactly) that it takes a really long time to do the console log parsing.  Based on the console output I'm guessing the JavaDoc parser (as the last message displayed is "[WARNINGS] Java Compiler : Found 0 warnings" and then 10-15 minutes later the Javadoc one is printed) is taking the longest.  The others seem to take a long time as well.

    Is there a way to make this run any faster or hints on making the console log less verbose?

    The logs are between 2-2.5 mb.

    1. You can redirect the JavaDoc generation output to a separate file.

  13. Hi Ulli,

    This is really a very useful plugin, but i have an issue with the files not beeing copied to the temp files.

    It says it needs an absolute path, but how can i do this if the .csproj is in a subdir ??


    1. What is the motivation about a new plug-in? You can already implement a new parser that scans for errors in the log.

      1. Yeah, i've seen that now,

        I've edited my comment, with a new issue.

        Thanks for your quick reply.

          1. Thanks,

            your comment pointed me in the right direction, and as it turned out it was legacy files in the svn repo.

  14. Does the "warnings to ignore" field only check against the filename of the files that are producing warnings and not the absolute path? I'm trying to ignore warnings from all of the files in a certain directory and it doesn't appear to be working.

    1. It works on the absolute filename. The pattern is a regular expression. What did you specify? Note that the paths are in UNIX format. Are there absolute filenames in the warnings.xml file in your build Folder?

      1. The filenames are absolute to the system root in compiler-warnings.xml

  15. Great Plugin!

    But since Jenkins has this new navigation line at the top, the relevant line in the source code lister/decorator is covered and not visible, just after a small scroll-up.

    Could it be possible that the source code lister would jump some 4-5 lines before the relevant line, and not exactly the one that is marked?

    Thank You...

    1. Ok, I see. I'm not sure if we don't have a general problem with this new approach: currently it is not possible to use the Firefox searchbox anymore, since the highlighted results are not visible due to the new header. Can you please file an issue so that this will not get forgotten?

      1. OK, I created a new improvement issue in Jira. Thank You.

  16. Hi,

    I want to use the warnings plugin to display results of cpplint from the console.
    I am getting the following exception: ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception
    at hudson.plugins.violations.util.AbsoluteFileFinder.addSourcePaths(
    at hudson.plugins.violations.types.cpplint.CppLintParser.parse(
    at hudson.plugins.warnings.parser.ViolationsAdapter.parse(
    at hudson.plugins.warnings.parser.ParserRegistry.parse(
    at hudson.plugins.warnings.parser.ParserRegistry.parse(
    at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(
    at hudson.plugins.warnings.WarningsPublisher.perform(
    at hudson.plugins.analysis.core.HealthAwarePublisher.perform(
    at hudson.tasks.BuildStepMonitor$2.perform(
    at hudson.model.AbstractBuild$AbstractRunner.perform(
    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(
    at hudson.model.Build$RunnerImpl.post2(
    at hudson.model.AbstractBuild$
    at hudson.model.ResourceController.execute(

    I am using warnings plugin 4.5 and violations plugin 0.7.10.
    If you need any further information, please ask.

    Thank you!

    1. Ok, I see. Seems that the violations plug-in requires a source code path. Can you please file a bug report in Jira? Either I need to patch the violations parser or I need to provide a source path entry box...

  17. How would i use this plugin?

    I cannot find anything to activate it in my job configuration?


    1. Then the plug-in is not installed correctly, did you install the requirements (analysis-core)?

  18. I had installed this plugin, and I found this plugin report the existing warnings as new.

    And other plugin meet the same issue (

    1. Is the path to the files relative?

      1. Thanks for your quickly response.
        I had checked the GNUCompiler4gcc-warnings.xml file.
        Looks like the filename is the relative path.
        And I just try to check 'Resolve relative paths' option in warning advanced configuration.
        But this issue still exist, Did you have any suggestion?

        1. What would help is a diff between the GNUCompiler4gcc-warnings.xml files of two builds. Can you please file an issue and attach the result?

          1. Thank you, you are so nice!!

            There have lots of differences between two builds, I had attached it.


            1. I had compare one warning, I found the Key and contextHashCode are different, FYI:

              <message>pointer targets in passing argument 1 of a€?chdira€? differ in signedness</message>
              <type>GNU Compiler 4 (gcc)</type>

              <message>pointer targets in passing argument 1 of a€?chdira€? differ in signedness</message>
              <type>GNU Compiler 4 (gcc)</type>

              1. Did the fix in the latest release work for you?

  19. Hi Ulli,

    this is an excellent plugin. I have been using it for a while and it works perfectly. However there is one feature I would really like: ability to send email if warning count increases from last successful build.

    Would you be able to provide a Groovy script (that I can execute in Jenkins script console) that shows how to compare warning count from previous build with the count from current build? I couldn't find anything like this in the Jenkins API documentation. If you can show me how to do this, I can probably figure out myself how to get the results into an email.


    1. Isn't that feature available when you set the build e.g. to unstable when a new warning is introduced? Then an email will be sent...

      If you want to use groovy you need to navigate the object model: maybe you can have a look at the email ext template at
      Here I navigate through the various results.

      BTW: the warning count is also available using the remote API, e.g. with http://localhost:8080/job/Freestyle/6/warnings2Result/api/xml

      1. Hi Ulli,

        thanks for the quick reply!

        You are correct, marking the build unstable does almost exactly what I need. The one extra thing would be if the email had the same text that is show on the Jenkins build details screen. Something like this:

        "Plug-in Result:Unstable - 4 warnings exceed the threshold of 3 by 1 (Reference build: #21)"

        I had a look at the Jelly template but I couldn't see how to get this information. How could I get this using the Jelly template?

        1. In the template you see the expression ${action.result}. The result is an instance of BuildResult (of the analysis-core plug-in). On this object you can use all public getters. E.g. the message you are referring to is from the project action summary.jelly:

          	<t:summary icon="${it.hasLargeImage() ? it.largeImageName : icon}">
          		<j:out value="${it.result.summary}" />
                  <j:out value="${it.result.details}" />  
          	    <j:if test="${it.result.hasError()}">

          So you can use e.g. the expression ${action.result.summary} to show the build summary in the Email (you need to use the Email-ext plugin)

          1. That's perfect. Thanks!

  20. Since updateing Jenkins to 1.481 and the Compiler Warnings Plugin to 1.416 (and 1.417 afterwards), I get the following NPE in several jobs: 

    ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception
    at hudson.plugins.warnings.WarningsResult.getFileName(
    at hudson.plugins.warnings.WarningsResult.getSerializationFileName(
    at hudson.plugins.analysis.core.BuildResult.getDataFile(
    at hudson.plugins.analysis.core.BuildResult.loadResult(
    at hudson.plugins.analysis.core.BuildResult.getProject(
    at hudson.plugins.analysis.core.BuildResult.getContainer(
    at hudson.plugins.analysis.core.BuildResult.getAnnotations(
    at hudson.plugins.analysis.core.HealthAwarePublisher.perform(
    at hudson.plugins.analysis.core.HealthAwareRecorder.perform(
    at hudson.tasks.BuildStepMonitor$2.perform(
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(
    at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(
    at hudson.model.Build$BuildExecution.post2(
    at hudson.model.AbstractBuild$
    at hudson.model.Run.execute(
    at hudson.model.ResourceController.execute(
    Any idea how to fix this?

    1. Seems that in one of your old builds (warnings 3.x) the compiler-warnings.xml file could not be read.

      1. Ok. And what can I do about that? Can I somehow manually change the reference build?

        I believe that this happened as I had turned off the plugin for a while due to the small bug in 1.416, so that the XML-file was not created. Maybe the plugin should be able to handle that case.

        If I ever have time for it again, I would be willing to try to fix the issue, but maybe Ulli can come up with a solution quicker?

        Oh, and I think I definitely need Inca Trail! ;-) Thanks for the great plugins and the quick response!

        1. Actually, the plugin handles that case already: it skips all builds where the plug-in has been disabled.

          I'm just wondering why there is a build result available but the file could not be read. I.e., one of your build (build.xml) files has a result
          (tag <result class="hudson.plugins.warnings.WarningsResult">) but this tag has no sub element group (like <group>Java Compiler (javac)</group>). In this case the build folder should have a file compiler-warnings.xml. This seems to be not the case. Did you manually change some XML files or delete xml files in these folders (just to be sure...)?

          I think I need to track this down to find the actual reason. Maybe I missed something when I tried to get the 4.x version backward compatible to the 3.x results. (Which actually will not work well if you have more than one parser installed.)

          Can you please file a new bug report in Jira? Maybe I need to add some logging messages so that we see for which build the NPE occurs.

  21. Since v4.0, each parser creates its own trend graph. When using a lot of parsers, this is quite annoying. Is there any way to get back the accumulated graphs?

    Ideally, a user should be able to specify which warnings to accumulate.

    1. Using only the warnings plug-in this is not possible yet. Did you already install the analysis-collector plug-in? This plug-in creates aggregated results of the warnings in a job.

      1. Oh, no, I haven't. I wasn't aware of that plugin. Maybe I should have reread the description of this plugin. Thanks!

  22. I am trying to use the FlexSDK parser with our AS3 project.

    The console is outputting several warnings, put they are not being parsed for some reason.

    Other projects are working fine (like GCC C++ project for example).

    Here is a sample warnings output: mxmlc C:\Program Files (x86)\Jenkins\jobs\YouPost\workspace\src\Engine\
    mxmlc Warning: declaration 'currentinputtext' will be scoped to the default namespace: Game: internal. It will not be visible outside of this package.
    mxmlc var currentinputtext:flash.text.TextField;


    1. Maybe the prefix 'mxmlc' is the problem. Please create an issue in Jira or/and attach an sample as raw text. (Or consider fixing the bug on your own, this shouldn't be complicated...)

  23. Hallo Ulli,

    I would like to send notifications to the developers who have warnings in their files. The notifications should be specific for each developers, containing the list of warnings they have.
    The "file responsible" would be the last person who modified the file where a warning occurred.
    Do you have any idea how I could proceed? Is it something which could be done with the Email-ext plugin based on your plugin outputs?
    Thank you in advance!


    1. This is not possible in the moment, see Maybe you can compute the result on your own using the email-ext plug-in. However, I think it makes more sense to add that feature to my plug-in.

  24. Hi all,

    I have a regular (not maven) job that gathers compiler and doxygen warnings. I want to set compiler a high prio and doxygen regular prio, so that i will be able to set status trash hold for each.

    The question is: how do I set different prio's for different  warning sources (doxy vs gcc compilation)? 

    1. This is not possible. All parsers share the same settings.

      1. Hi Ulli, So why there is a trash hold per priority, for maven only? Is this a feature that can be implemented?

        1. One threshold per priority, yes. This can be implemented, mostly UI changes: the complicated thing would be how to present that information in a simple way in the UI to the user? Maybe it makes sense to implement such a feature when is done.

  25. It seems that reference build is calculated in wrong way: it always tries to take last stable. while I didn't select that flag in  job configuration. That causes false alarms. I work with pylint warnings, beside that it is very similar to this issue:

    My warning plugin version  is 4.35

    Ulli, can you advise? 

    1. The reference build is the build you started to use the warnings delta. It might be stable or not.

  26. It seems that all warnings graphs behave in wrong way: No matter what compiler i choose to show, i get total count. It happens even if i choose to present stats of a compiler that i don't check at all. 

    1. Please create an issue.

  27. Hi

    Since upgrading from Warnings plugin 4.35 to 4.36 one of our job fails with:

    ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception Error: No warning parsers defined in the job configuration.
    at hudson.plugins.warnings.WarningsPublisher.perform(
    at hudson.plugins.analysis.core.HealthAwareRecorder.perform(
    at hudson.tasks.BuildStepMonitor$1.perform(
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(
    at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(
    at hudson.model.Build$BuildExecution.post2(
    at hudson.model.AbstractBuild$
    at hudson.model.Run.execute(
    at hudson.model.ResourceController.execute(

    It was true that no warning parser was defined in the job configuration but should the plugin give an exception in this case? (It didn't in 4.35).


    1. Due to JENKINS-20454 gcc parsers have been removed from the configuration. This has been fixed in 4.37.

      You must specify a parser when you enable the plugin, this beahavior is quite old.

  28. Hi 
    I am having problems using the warning plugin. I have made my own parser.  I am parsing a csv file containing the log output, but when I have several warnings in the same line the plugin only parses the first warning.

    From what I under stand the plugin is not able to receive information regarding the column

    Regular expression:

    my groovy script:

    import hudson.plugins.warnings.parser.Warning
    String fileName =
    String lineNumber =
    String category =
    String message =
    return new Warning(fileName, Integer.parseInt(lineNumber), "Dynamic Parser", category, message);

    example Lines to parse:
    "C:\svn_working\AF0500\Platform\dbg\dbg.c","No comment with variable declaration","307","41","param_level","Static Global Object","All Checks\Language Specific\C and C++\Variables\Variables should be commented","Each variable declaration should have a comment"
    "C:\svn_working\AF0500\Platform\dbg\dbg.c","No comment with variable declaration","307","30","param_idx","Static Global Object","All Checks\Language Specific\C and C++\Variables\Variables should be commented","Each variable declaration should have a comment"
    "C:\svn_working\AF0500\Platform\dbg\dbg.c","No comment with variable declaration","307","21","cmd_idx","Static Global Object","All Checks\Language Specific\C and C++\Variables\Variables should be commented","Each variable declaration should have a comment"

    The result: only the first line i parsed

    I am doing something wrong or is the plugin not able to multiple warning in the same line ?

    Kind Regard
    Bo Vestergård

    Dump of warning plugin configuration:

    1. If you have multiple warnings in the same line then you need to set the column as well (setColumnPosition). Otherwise these warning are considered the same (if the other properties are the same).

      1. Hi Ulli

        Thanks for your quick response.

        This is my first attempt to make a parser, so I am not a specialist. 

        when at look at the definition of the warning ( I cannot see it is possible to set the column position

        I have tried to do like this:

        An excep

        import hudson.plugins.warnings.parser.Warning
        String fileName =
        String lineNumber =
        String columnPosition =
        String category =
        String message =
        return new Warning(fileName, Integer.parseInt(lineNumber), Integer.parseInt(columnPosition ), "Dynamic Parser", category, message);

        An exception occurred during evaluation of the Groovy script: Could not find matching constructor for: hudson.plugins.warnings.parser.Warning(java.lang.String, java.lang.Integer, java.lang.Integer, java.lang.String, java.lang.String, java.lang.String)

        I have also note that the IAR parser, Gets the number of warnings wrong. the number of the parsed warnings result is lower than the numbers counted by the compiler - Also because of multiple warnings in the same line of code

        When I read your answer it seems very simple, but I cannot figure out what I am missing or doing wrong

        Kind regards

        Bo vestergård


        1. Actually there is no constructor available using column positions yet. You need to use the setter (after you instantiated the warning). The setter is available in the base class:

          1. Ahhh now I got it. Thanks Ulli

            my script after update:

             import hudson.plugins.warnings.parser.Warning
            String fileName =
            String lineNumber =
            String columnPosition =
            String category =
            String message =
            Warning myWarning = new Warning(fileName, Integer.parseInt(lineNumber), "Dynamic Parser", category, message)
            return myWarning;
            1. Good to see! I should update the help with your example...

  29. Great plugin!  But I am having a couple of issues. 

    First, using the MSBuild parser it is picking up Errors as well. Not a bad thing really except it reports them as Warnings not Errors.  If that's not a known issue and you need more info let me know.

    Other thing is really a question, I have done my own parser in the config screen to get MSBuild Errors and it's working fine but in all the reporting areas it says Warnings, is there an easy way for me to change what the reports say?

    Hoping to avoid having to modify the plugin code itself.

    btw, this plugin would be 1000 percent better if you added Error capture as well. Having the Warnings and Errors in combined reports would be very useful and, I think, make this plugin even more valuable to everyone. Yes Jenkins has some of this built in but not to the degree your plugin does it, drilling down into the files, lines of code, etc.



    1. First of all: there is no UI configuration of the individual parsers available up to now. If you want to change the behavior you need to change the source code of the corresponding parser.

      Currently the warnings plug-in does not support errors yet. Some parser authors circumvented that restriction by creating a warning with priority high if the log actually contains an error. But that is just a workaround. We already discussed that in the mailing list a couple of month ago: the conclusion was (at that time) that it would make sense if Jenkins core would provide such a feature. However, maybe it would be simpler if the warnings plug-in would parse and display compile errors. This shouldn't be so hard to change and some of the parsers already parse the errors. Can you please file a feature request in Jira so we can gather the requirements first? I think there are several UI changes required to support errors.

      1. Thanks. Feature request has been created. JENKINS-22700

  30. Hi

    Thought I'd ask here first.. I've got the most recent warnings, token-macro, analysis utilities and analysis core installed on a 1.514 Jenkins installation. Do you know if there's any incompatibility in there that might be the cause of the "Details" section of the warnings page to be empty? I've got another Jenkins 1.520 with some older versions of those plugins that looks fine.

    The versions are:

    Jenkins 1.520, analysis collector 1.35, analysis utilities 1.49, token macro 1.7, warnings 4.26

    Jenkins 1.514, analysis collector 1.41, analysis utilities 1.56, token macro 1.10, warnings 4.40

    I can't see a specific issue mentioned in Firefox but in ie8 it seems to report an issue with the YAHOO.plugin.dispatcher being null or something like that.

    Any help would be greatly appreciated.

    1. Not that I'm aware of. Do the plugins work on a more recent Jenkins version on your machine?

      1. Do you mean more recent than 1.520? I haven't tried. I have a colleague who may have a more recent version on his system; I'll see how that goes.

        1. It turns out the colleague has the same version as on the server (the 1.514 version), however I've just installed the plugins in his version and they seem to work a treat! Must be some other screw up.

          Thanks for your time!

    2. Aaaaarrrrggghhhh - I found out the javascript files in the analysis-core plugin had been McAfeed; instead of being in the relevant folder there were two "x-warning.txt" files showing they'd been removed as McAfee didn't like their extension! Replaced the files and it works fine.

      As far as McAfee/server etc is concerned - don't ask - I have no control over that!

  31. Hello, I just started to introduce Jenkins in our companys build process (Win32/msbuild), and it works well: SVN / msbuild / Logparser / Email / etc. are fine. BUT:

    It's currently not possible for me, to see/use the 'scan for compiler warnings' of the warnings-plugin. The entry is still missing in the dropdownbox of the [Add Postbuild Step] (see screenshot blow). As far as I can see, all needed plugins are the active (pls. see below). The 'Code Analyis PlugIn' is shown under 'Configure System'.

    I assume a basic configuration issue on my side and therefore scanned this thread and the Jenkins-Issues, but did not find a soltuin for my problem - nor any body else, who experiences the same problem. (sad)

    Could you pls. give my hint, what I still can check to find the cause? Thanky you for your support!



    ver. 1.564


    Firefox 29.0.1














































    1. SOLVED

      I installed Jenkins and the plugins above on a second Windows machine (Win81/32) and it works: I now see PostBuildAction 'Scan for Compiler Warnuings'.

      So it must be a configuration/installation issue on my first machine (Win81/64). Or: may it be a significant difference, that my problem only occurs on a a Wion 64-bit machine? (I assume - no).

  32. A word of warning: if you see your builds disappearing after you activate Warnings plug-in, make sure to enable Maven plug-in.

    See JENKINS-21268 for details.

  33. I'm not seeing a trend graph appearing for my job and am not sure why.  I'm using the following:

    Jenkins: 1.583

    Warnings plugin: 4.42

    Static Code Analysis: 1.61

    Static Analysis Collector: 1.41

    (Edit: removed error info)

    I've tried downgrading to Static Code Analysis 1.58, thinking that might be the culprit, but I encounter the same thing -- same JavaUtilLog warnings and no trend graph.

    Any ideas?  Am I misconfiguring something or am I simply missing an appropriate plugin?

    Update: It turns out that the trend graph will not be displayed until you have a successful build.  I set my Lint configuration to fail if any Lint errors are found.  Changing the Lint scripting so that the job succeeds in spite of Lint errors finally returned me a trend graph.  I subsequently set the warning threshold to 0 which causes the build to be marked as a fail.

    1. I see. There is an option in the plug-in configuration to run the plugin even if the build has been failed.

      1. Yes.  I had that enabled - but no trend graphs were created.  Everything else seemed to be working correctly... I was getting results that were all nicely interpreted and annotated.  Just, no graphs.

        1. Just checked the code and the graph should be shown in your case. Seems that this computation is somewhat broken. If you don't mind: can you please file a bug report so that this will not be forgotten? If I find some time I'll investigate this (small) bug.

  34. Is there any way to maintain some state in the Dynamic Parser script between matches? I'd like to create a variation of the Make+GCC parser that stores an absolute path in a variable that can be used to resolve all the relative paths.

    Looking at, a new Binding is created for every execution of the script, so I guess it's not currently possible to maintain any state? It seems like the binding could be stored as a private member of GroovyExpressionMatcher, like the compiled script is? Then the script can add new variables to the binding using the Field annotation? My Java is rusty and I have very little experience with Groovy, so I'm not quite sure how this would all work.

    1. Yes you are right, this is not yet supported. I don't know how this could be solved, I never looked into the details of the Groovy runtime, too. The current implementation is copied from some tutorials (smile)
      Maybe it would be easier to write the parser in Java and deploy it as a separate plug-in.

      1. I have a PR that persists the binding across matches.

  35. Is it possible to use build parameters or environment variables in the threshold properties?

    Can I do something like:

    I'm investigating creating a generic build pipeline, so would have to pass in the thresholds somehow. Or is there some other better way to do this?

    1. Sorry, this is not possible.

  36. I'm trying to use the Warnings variables, WARNINGS_COUNT for example, but they do not contain any value, I'm trying to use them just after the Scan.  Are the ones documented not the correct names?

    1. Seems that I never updated the tokens to use aggregated results. Can you please check if the latest CI build works?

      1. How do I get that?  Sorry I've just never had to get a CI version of any of the plugins before so not sure where to get that.

        1. Sorry, I thought I posted the link inline (the build status is at top of the wike page of each my plugins):$warnings/
          Just replace your warnings.jpi with the warnings.hpi file.

          1. That did not fix it for me.

            1. btw, the WARNINGS_RESULT does sort of work. It shows a value but the value says Success even though in this case the build is Unstable because of the number of Warnings.

              It seems like something that would normally keep the Count and also the Result values up-to-date is no longer doing so, if that help.

              Question on this whole thing. Since you can do multiple parsers and that generates separate reports for each parser are the results for each kept separately as well?  So something like MSBUILD_WARNINGS_COUNT?

              1. No, the values should be shown aggregated only.

                Can you please file a bug report in Jira and add an example setup with the expected result.

  37. Status threshold (total) not triggered when total results from two warning parser exceeds the limit

    I am maintaining a project using your warning plugin.
    I am using two parsers: MSBuild and my own custom for Parsing Green Hills System compiler warnings
    I want to set the health limits, so I open the "advanced " and set the 
    Status thresholds (Totals) All priorities Priority high Priority normal Priority low
     yellow |      |
     red      | 31 |
    Output from the parsers:
      FOSS_GHS_PARSER: 24 warnings.
    • Plug-in Result:  - no threshold has been exceeded (Reference build: #651)
    • Still 5 days before reaching the previous successful builds highscore.
      MSBuild Warnings: 18 warnings.
    • Plug-in Result:  - no threshold has been exceeded (Reference build: #651)
    • Still 4 days before reaching the previous successful builds highscore.

    My project is currently having a total sum of warnings at 24 + 18 but the project is not marked as failed.If the warnings from one of the parser exceeds the limit - Then the build is as failed.

    Want am i Doing wrong ?

    Kind regards
    Bo Vestegård
    Foss Analytical, Denmark 

    1. Which version are you using, this should be fixed in latest...

      1. Aaarrrrhhhhhghghghg I was not using the latest version.

        Sorry for the interruption and thanks for a very nice plugin

  38. Hi, does this support gradle compile warning output?

    I'm using javac parser, but no detected(I'm sure the gradle output log has compile warnings)

    1. I think nobody explicitly added support. So if there are warnings and they are not recognized, then the answer is probably no. This should be easy to fix, interested in providing a pull request?

  39. Is the "GNU Make + GCC" Parser for GCC 4 or GCC 3? I assume GCC 4, but is that true? Maybe it would be nice to explicitely put this into the name!

    1. Yes it is. The name can't be changed again (it already has been renamed). Otherwise the old results will not be mapped correctly.

  40. Hello,

    I'm not sure if I'm having an issue with the Warnings Plugin itself, or the Static Analysis Collector Plugin. But in my job I have 2 warnings parsers setup to scan workspace files (JSLint and PyLint in my case), and only the first one gets included in the aggregate static analysis warnings count and graph. Both parsers execute and have correct counts and show up in the build details though.

    I tried reversing the order of the two parsers, and the aggregate count changed to be short by exactly the number of warnings found for the second parser.

    Is this a known issue?

    I'm using Warnings Plugin v4.45, Static Analysis Collector Plugin v1.42, and Static Code Analysis Plugin v1.67.

    1. Seems to be a bug, can you please file a bug report in Jira?

  41. hi, Great plugin!  But I am having a couple of issues.

    Jenkins: 1.607

    Warnings plugin: 4.46

    Static Code Analysis: 1.70

    Static Analysis Collector: not installed

    File pattern: results/*.log

    Parser: GUN Make + C Compiler(gcc)

    issue: i found there is the inconsistance between the warning totality reported by warning plugin and  results/*.log itself.

    all full build logs will placed under results folder, i check the warning api files which shows all warnings with ~12000

    Now when I run a simple command in the workspace : cat *.log | grep --I warning: | wc-l , results is ~46000 warnings

    why the result looks so many differences between them?

    then i try to check the log files one by one, but found another strange problems:

    at the end of the build console output, there is warning plugin output:


    17:27:51 [WARNINGS] Parsing warnings in files 'results/*.log' with parser GNU Make + GNU C Compiler (gcc)

    17:27:58 [WARNINGS] Finding all files that match the pattern results/*.log

    17:27:58 [WARNINGS] Parsing 15 files in /home/jenkins/workspace/***-DAILY-START

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/1.log with 0 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/2.log with 730 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/3.log with 778 unique warnings and 687 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/4.log with 778 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/5.log with 778 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/6.log with 2127 unique warnings and 7 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/7.log with 2203 unique warnings and 408 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/8.log with 2203 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/9.log with 2203 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/10.log with 2249 unique warnings and 5 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/11.log with 2250 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/12.log with 12400 unique warnings and 312 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/13.log with 12734 unique warnings and 10134 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/14.log with 12734 unique warnings and 0 duplicates.

    17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/15.log with 12734 unique warnings and 0 duplicates.

    17:28:08 [WARNINGS] Computing warning deltas based on reference build #135

    17:28:12 Archiving artifacts

    17:30:36 No emails were triggered.


    the result is also different with  ~12000 which reported by warning plugins.

    forthermore, i pick up one log file to check the warnings:

    in console above:  17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/7.log with 2203 unique warnings and 0 duplicates.  -------2203 unique warnings

    by commond: 

    cat /home/jenkins/workspace/***-DAILY-START/results/7.log | grep -I warning: | wc -l

    1  --------the result is 1 warnings, in fact it really does when i open the file.

    which is the right warning result, all above makes me confusing.

    1. The reason is visible from the log (wink)

      17:27:58 WARNINGS Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/13.log with 12734 unique warnings and 10134 duplicates.

      There are a lot of duplicates in there (same properties).

      For the totals in one file: Can you try with just this file?

      Please use the issue tracker for bug reports...

      1. thank you for you quickly response.

        so the 12734 should be the totality warnings which added all warning result from every log files? for example:

        17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/3.log with 778 unique warnings and 687 duplicates.

        17:27:58 [WARNINGS] Successfully parsed file /home/jenkins/workspace/***-DAILY-START/results/4.log with 778 unique warnings and 0 duplicates.

        778 in 3.log = (warnings in 1.log)+ (warnings in 2.log)+ (warnings in 3.log), and so does the duplicates warnings? if so, there should be also 687 duplicates warnings in 4.log.

        BTW, what does the 'same properties' mean? if the same warning but in different code line, it will consider as the duplicate warnings? 

      2. hi, i've create to track this issue.

        thank you so much.

  42. Am 01.02.2016 um 19:19 schrieb John Mellor <>:

     I really like the concept of the Warnings Plugin, but I’m having some difficulties correctly setting it up in Jenkins.  I’m running essentially the latest of everything, but have a remaining blocker issue.

     I run about 350 jobs on Jenkins for several products.  My prototype project is a large C++ job, building on typically 2 versions of Ubuntu in sequential pbuilder environments on one of a cluster of slave machines.  All jobs are freestyle jobs, typically run with simple shell scripting.  All build .deb deliverables in this case.  There are presently 13 possible slave machines, which will get selected by Jenkins mostly depending upon the restricting labels of the particular Jenkins job.

     So far, its been pretty easy to configure and run, but I’m stuck.

     The first issue that I worked around was that there were twice as many warnings being reported as were actually present.  This was due to my initial configuration to scan the build log instead of scanning the log for only one platform.  Since the source is compiled twice (once on each platform), this was probably the wrong thing to do.  Instead, I switched to only looking at a build log from one platform, not the job log.  I picked the environment with the newest gcc compiler, which would give me the most accurate warnings reporting.  Problem solved.

    Ullrich responded:

    > Is this a matrix job? Then the corresponding log should be automatically picked… If not then the best way is to pipe the warnings to 2 different files and use the correct file as input. 

     No.  Its a freestyle job.

    John continued:

    The second and more serious issue is that drill-down for specific warnings does not work.  It looks like there is an assumption that the source file location is the same as on the Master node.  This would appear to be due to 2 failing assumptions:

    a)      In my case, the master node typically does not have the source.  It is pulled from git on the slave machine that it picks.  So, the workspace is not present for that build on the master node – only the artifacts, the build number,  the project configs and a couple of Last-<whatever> symlinks are on the master node.  Is the plugin supposed to pull the source tree from the slave machine, or how was this supposed to work?

    b)      I’m building in a pbuild environment (essentially a chroot jail), and the source tree is present at build time in /tmp directory.  This environment is then destroyed at the end of the build for that platform, and the only existing copy of the source tree is in the workspace directory of this slave machine.

    So, on the master node, no source tree exists.  On the slave machine, it is different than what is noted in the build logs.  How do I get this to work?

     Ullrich responded:

    > The files are copied from the slave to the master after the build. If something went wrong, the exception message is copied into the file as text. From the attachment below I see that a file could not be found. (See inline comments below)

    John expanded:

    I’ve attached a typical traceback shown in the window that occurs when I drill down to a specific error, to show the problem.

    Any ideas?

    <included traceback deleted to save test space>


    1. Content of file archiver.h
      01 Copying the source file '/tmp/' from the workspace to the build folder 'ed9a8377.tmp' on the Jenkins master failed.
      02 Is the file '/tmp/' a valid filename?
      03 If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/job-name//tmp/‘

      Is the file


      correct? Is the file readable? Is the file still available on the slave after the build (the warnings plug-in runs after any build step)?

  43. Is there an example on how to ignore files with space in the absolute path name, like:

    C:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/V120/Microsoft.MakeFile.Targets

    I tried it plain, with quotes ("C:/Program Files (x86)/MSBuild/Microsoft.Cpp/v4.0/V120/Microsoft.MakeFile.Targets") and with space replaced by \s (C:/Program\sFiles\s(x86)/MSBuild/Microsoft.Cpp/v4.0/V120/Microsoft.MakeFile.Targets) but it won't work either way.

    Someone who knows how to correctly ignore this file?

    1. This is a regular expression. Can't you just try something like

      1. Thanks!

        That worked perfectly.

  44. Does the log files need to be in a specific format? I have saved my ARMCC build output to a log file and when trying to run this plug-in against that it doesn't find any warning, however if the log file is printed out into the Jenkins console output and analyzing that, the warnings are found.

    1. No, this is the same format and parser. Is the correct file found? There should be a logging statement in the console log.

      1. I have a log file which is pretty much the same content as appears in the console log. In the build producing the log file I run the plug-in on the console log and it finds the warnings fine. On the parent build I try to run the plug-in on the log file (transferred as artifact) but it doesn't find any warnings. I can see in the parent build's console log that the plug-in found the log file and didn't found any issue in it.

        1. Hmm, then it looks like the file transformed the messages somehow. You can check on your own by creating a unit test for the armcc parser that reads your file. Did you try a diff between file and console? (the console is also stored in a file in your build folder)

          1. Found the problem. My log files were saved with UNICODE encoding.

  45. Hey Ulli,

    is it possible to generate an output file?

    Like .xml or anything like that? I would like to save the warnings in a file for my deployment of each version.

    1. You can either use the remote API to extract the content of the result or you can copy the result XML file from the build folder. 

      1. I can't finde the .xml result output in my build. Could you tell me how the default path is configured in the plugin? Root of the workspace?


        1. The file is in the build folder of your Jenkins master, all Jenkins serialization files are stored there.  

          1. Thank you very much Ulli, I found it.

  46. C Z

    MSBuild parser wrong parse msbuild15 output. In log i have  lines like this:

    17:4>Filters\FilterBuilder.cs(229,34): warning CS0168

    As a result, i see «... Failed to copy d:/workspace/ .../Filters/17:4>Filters/FilterBuilder.cs ...»,message when I try to see the warning.

    Used 4.64 version. 

    1. Please do not report bugs in the wiki, use the issue tracker

      1. C Z

        Ok. I created JENKINS-48647

  47. Hi,

    I'm trying to use Warnings with pylint. So I have such a file hierarchy:

    - app/project_name/

    - app/lint_report.txt - file generated during build with pylint results (on )

    Using Warnings on "app/lint_report.txt" works OK, but when I try to open file which is a source of warnings I've got an error mesage:

    Copying the source file 'project_name/' from the workspace to the build folder 'foo.tmp' on the Jenkins master failed.
    02 Seems that the path is relative, however an absolute path is required when copying the sources.
    03 Is the file '' contained more than once in your workspace?
    04 Is the file 'project_name/' a valid filename?
    05 If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/[job-name]/project_name/'

    Seems like Warnings plugin does not use the `app` part of the path.

    Checking `Resolve relative paths` in settings does not help.

    How it can be fixed?

    1. You can configure pylon to output an absolute path.

  48. Hi,

    We are running into error when we scan for compiler warnings with LLVM/Clang parser on console log. When I click the graph and report log, I end up with:

    01 Copying the source file '2017-12-20 07' from the workspace to the build folder '992d7346.tmp' on the Jenkins master failed.
    02 Seems that the path is relative, however an absolute path is required when copying the sources.
    03 Is the file '2017-12-20 07' contained more than once in your workspace?
    04 Is the file '2017-12-20 07' a valid filename?
    05 If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/[job-name]/2017-12-20 07'
    06 If you are building on the master: please check if the file is accessible under '$JENKINS_HOME/[job-name]/workspace/2017-12-20 07'
    07 Failed to copy 2017-12-20 07 to JENKINS_HOME/job-name/builds/16/workspace-files/992d7346.tmp
    08 at hudson.FilePath.copyTo(


    Plugin Version: 4.52(It does not work if we update the version to the latest one)

    Definitely, there is no file named '2017-12-20 07' in master workspace or on the slave. The plugin should scan for console log but I assume its not happening. '2017-12-20 07' looks like timestamp of the actual file. When I look into ClangLLVMbased-warnings.xml on master and seed the <fileName> tag contains this timestamp instead of the actual file name. See the attachment. Can you please help?


  49. Seems that your log does not only contain the LLVM/Clang output: somehow timestamps are available there. Can you please create an issue and add such a console log message that is parsed in the wrong way.

  50. Hi Ulli,

    Yes, in the console log I can see some timestamps as below(Please note: this is another build log and not the one i mentioned in the above comment. I have lost that build)

    (I am afraid I can post the complete log coz of security reasons)

    Test Suite 'JSONModelTests' passed at 2018-01-22 03:03:22.063.
    Executed 17 tests, with 0 failures (0 unexpected) in 10.605 (10.610) seconds
    Test Suite 'LaneDefinitionTests' started at 2018-01-22 03:03:22.064
    Test Case '-[LaneDefinitionTests test_sortWidgetDefinitions]' started.
    Test Case '-[LaneDefinitionTests test_sortWidgetDefinitions]' passed (0.000 seconds).
    Test Suite 'LaneDefinitionTests' passed at 2018-01-22 03:03:22.065.
    Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
    Test Suite 'LaneTitleAttributesTests' started at 2018-01-22 03:03:22.065
    Test Case '-[LaneTitleAttributesTests test_font]' started.
    Test Case '-[LaneTitleAttributesTests test_font]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_fontSize]' started.
    Test Case '-[LaneTitleAttributesTests test_fontSize]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_horizontalAlignment]' started.
    Test Case '-[LaneTitleAttributesTests test_horizontalAlignment]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_init]' started.
    Test Case '-[LaneTitleAttributesTests test_init]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_striketrough]' started.
    Test Case '-[LaneTitleAttributesTests test_striketrough]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_textColor]' started.
    Test Case '-[LaneTitleAttributesTests test_textColor]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_titleText]' started.
    Test Case '-[LaneTitleAttributesTests test_titleText]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_underline]' started.
    Test Case '-[LaneTitleAttributesTests test_underline]' passed (0.001 seconds).
    Test Case '-[LaneTitleAttributesTests test_verticalAlignment]' started.
    Test Case '-[LaneTitleAttributesTests test_verticalAlignment]' passed (0.001 seconds).
    Test Suite 'LaneTitleAttributesTests' passed at 2018-01-22 03:03:22.074.
    Executed 9 tests, with 0 failures (0 unexpected) in 0.007 (0.009) seconds
    Test Suite 'LeastSquaresTests' started at 2018-01-22 03:03:22.075


    Is it that these timestamps are getting in place of the actual filename. I am do not have the knowledge in the language the plugin is written. I would appreciate any help w.r.t this. 

    1. This part in not responsible for the problem, see

      If this happens again, please file a bug report in JIRA and attach the corresponding console log that contains the warning part. 

  51. where do i find detailed information on how to use "Release 4.62 Added a new symbol for pipelines: warnings" ?

    1. You will see the result in the snippet generator. There is no other documentation since the call just has been simplified to warnings params.

  52. just wonder whether this plugin support Pipeline DSL?

    1. Hi Ulli,

      Thanks for your answer. Could you pls point me to where i can find the sample code for Pipeline DSL.

      Thanks again.

      1. I don't have one, I don't use the DSL. You should try your luck on the mailing list. (If you get an answer: please post your result on the wiki page so that others can use that example as well)

        1. thanks. sure will do once get it working

        2. I could not get any reference for using this in DSL/Declarative Pipeline, can you please here or point me in correct direction?

  53. I have updated warnings plugin from 4.40 version to latest version 4.65 . I use warnings plugin on IAR compiler(C/C++) to parse reports of txt/xml format.

    But I found huge performance drop between two versions. With earlier warnings plugin version my job use to run is 45 min (30+10(min for post build actions). 

    After updating of Warnings plugin job duration increased to 3.5 hrs (30+ 3hrs(post build build actions).

    Whole 3 hrs is been taken only by warnings plugin while parsing reports . 

    Note: My configurations on warnings plugin are unchanged between two versions.

    Please help me with this issue. I am happy to share my logs if you need any.


  54. Your Plugin is great!

    Any thought of cloning it to parse errors instead of warnings?

    They would go great together.

    "Errors Plugin"

    Thank you,


  55. It can parse errors as well, at least in the lasted development branch. What still needs to be done is to add some parsers that actually scan for errors. 

    Which parsers are you expecting to scan for errors? Do you have any ideas how these errors should be displayed (see JENKINS-22700 for details).

  56. I'm mostly interested in the vars: Count, New,and Fixed,

    I run a 'Execute shell' as last Build Step to grep on the raw console to get my tailored list from Java errors as part of the html report sent to email;

    grep -v 'DistributeSoftwareRepositories\|ServiceManager\|Inserting alarm for deleted resource' /server/server-runtime/target/server/logs/my-server.log | grep -C10 'ERROR\|Entity version mismatch' | head -100 > /loadtestnew/target/jmeter/results/load-testnew_server_errors.log

    Job is Triggered by commit - Warnings:

    I was thinking if you copied the plugin and used [ERROR] instead of [WARNING] to create another set of email Tokens.

    I guess the next logical step after would be to define Custom capture "Strings";

    Could be drop-down Name=Value parameters in the job config: SearchString_Name and SearchString_Value.

    myString = String; #Examples: ( SQL, NULL, POST, HTTP 200, etc...)

            <TD style="padding:3px;">$myString_COUNT</TD>

            <TD style="padding:3px;">$myString_NEW</TD>

            <TD style="padding:3px;">$myString_FIXED</TD>

     This would allow you to count any type of String Data, not just warnings and errors:






    1. I'm not sure if I understand your requirement. The tag [WARNING] is not parsed at all (or only by a specific parser). Which parser are you using? 

  57. I'm not sure, but it seems we look at the problem and the solution differently.

    We are talking about LOG files, right? (Console, Server, HTTPD, etc...)

    They are all text. I do not concern myself with a particular parser, only the ability to find a String and count it.

    You have already done the hard part by comparing to previous build(s).

    It does not matter if windows ( \ ) or Linux ( / ), or Java or C++, you could account for this in the string qualifier, if needed.

    I don't understand the concern with exotic parsing. Jenkins is written in Java, so the only concern is how to get to shell from Java.

    Maybe you are performing more magic behind the scenes, but any form of "grep" should work.

    grep -c string $logfile or (cat $logfile | grep -c string)

    grep -c string $Prevlogfile

    I could write it as a shell script or batch file and simply export the vars back to the environment



    1. I see, you want a very simplistic parser that scans in log files for a TAG (like grep does). The existing warnings plugin parsers are much more powerful (wink) 

      I can add such a parser (with configurable TAG), can you please file an issue in our issue tracker? 

  58. Hi Ulli,

    Could you provide the link for the issue tracker?

    my "RegEx Grep Parser" submission is something like:

    export mySearchValue="MySearchString"

    export mySearchPath="path_to_server.log"


    grep command: export myString_Count=$(grep -c $mySearchValue $mySearchPath)

    Requirements: VarCountName, VarSearchValue, Path_to_Log(s)


    Thank you,


Write a comment…