Log Parser Plugin

Plugin Information

Plugin ID log-parser
Latest Release 1.0.8
Latest Release Date Dec 14, 2010
Sources Subversion
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla

Parse the console output and highlight error/warning/info lines.

New homepage
This plug-in is being maintained by the owner from a new home. The plug-in is still compatible with Hudson, however, the entry points for documentation and issue reporting have been combined in order to provide a single point of entry.


Quick Overview

The log-parser plugin allows to parse the flat console log generated by the Hudson build. It does this by :
- highlighting lines of interest in the log (errors, warnings, information)
- dividing the log into sections
- displaying a summary of number of errors , warnings and information lines within the log and its sections.
- linking the summary of errors and warnings into the context of the full log, making it easy to find a line of interest in the log
- showing a summary of errors and warnings on the build page

Labels:

tier3-compat-plugin tier3-compat-plugin Delete
plugin-report plugin-report Delete
tier3-hudson-plugin tier3-hudson-plugin Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Apr 18, 2010

    Varun Thakur says:

    Hi , Can you also publish the compatibility information as the plugin did not wo...

    Hi ,
    Can you also publish the compatibility information as the plugin did not work with the supported version of hudson (1.3.12)

  2. Apr 23, 2010

    Sagar Khushalani says:

    I tried running this with the latest version of Hudson (1.355) but was not succe...

    I tried running this with the latest version of Hudson (1.355) but was not successful. Has anyone tried it yet?

    Also, the format for the parsing rules file: Is it

    _error /ERROR/_

    or

    error /ERROR/

    (with or without the underscores?)

    Awesome plugin, thanks!

  3. Jun 18, 2010

    christophe mertz says:

    Hi, works fine for me on Hudson ver. 1.362 Very nice plugin. The correct parsi...

    Hi,

    works fine for me on Hudson ver. 1.362 Very nice plugin.

    The correct parsing rule is :

    error  /ERROR/

    And important point : default directory where for the parsing rule file is the directory which contains the jobs/ dir

    1. Jun 29, 2010

      Paul Spencer says:

      However much I try I always get: log-parser plugin ERROR: Cannot parse log: ...

      However much I try I always get:

      log-parser plugin ERROR: Cannot parse log: Can't read parsing rules file:wc-TCK-parsing-rules
      

      At the moment I'm copying it to the $T_WORK directory. I've tried copying the parse rules file to /tmp and accessing it there.

      This plugin looks like just what I need, any ideas?

      1. Jul 14, 2010

        Paul Spencer says:

        Silly me. The parser file has to be accessible to the hudson instance. I had m...

        Silly me.

        The parser file has to be accessible to the hudson instance. I had my jobs running on remote machines and had put the parser files there.

  4. Jun 21, 2010

    David Ringhofer says:

    Somethings wrong with the paths to the CSS-file in Hudson ver. 1.363. eg. the l...

    Somethings wrong with the paths to the CSS-file in Hudson ver. 1.363.

    eg. the link points to
    /hudson/css/style.css

    while it should be

    /css/style.css

    1. Dec 08, 2010

      John Borghi says:

      Hi David, Indeed, the links appear to have a hardcoded 'hudson' prefix. It shou...

      Hi David,
      Indeed, the links appear to have a hardcoded 'hudson' prefix. It should be relative to the Hudson web root.

      Opened bug: http://issues.hudson-ci.org/browse/HUDSON-8268

      Thanks! Will fix in the next release.

  5. Aug 06, 2010

    Thomas Oswald says:

    The directory from which the search for the parsing rule file begins is NOT alwa...

    The directory from which the search for the parsing rule file begins is NOT always the directory which contains the "jobs" directory.

    It is the current working directory of the process which starts the Hudson (only Windows platforms; other platforms i don't know).

    Example:

    1. Hudson is started through a batch file which is located in the directory "C:\Program Files\Hudson". Then this folder is the starting folder for the rule files.
    2. Hudson is started as a windows service. Then the "%windir%\system32" or "%windir%\syswow64" folder is the starting folder for the rule files.

    I think this is a bug of the plugin. The search should always start at "HUDSON_HOME". An other solution is that the plugin accepts environment variables in the file path for the rule files (this doesn't work at the moment too).

    1. Sep 17, 2010

      Sorin Sbarnea says:

      I think that current configuration storing method is making this great plugin no...

      I think that current configuration storing method is making this great plugin not practically usable.

      I added a feature request to move the configuration inside the job configuration, feel free to vote it and add your opinions there. http://issues.hudson-ci.org/browse/HUDSON-7490

      1. Oct 06, 2010

        Sorin Sbarnea says:

        Due to the hardcoded path in the config it is impossible to use the plugin in a ...

        Due to the hardcoded path in the config it is impossible to use the plugin in a multiple OS hudson setup. For example I have the hudson server running on OS X but all my jobs are executed by nodes running Windows. Due to this I can't use the plugin because there is no workaround to delivery the configuration to the slave.

        Probably the easiest solution for this would be to modify the plugin to change the current directory to the workspace root. This would enable us to put the parser config file in the SCM.

  6. Aug 26, 2010

    Lucas Hedding says:

    It would be nice to have the option to store parser rules in a text box from wit...

    It would be nice to have the option to store parser rules in a text box from within the hudson GUI, rather than a file. I don't have file system access on our hudson server, but I do have admin access in the GUI.

    EDITED:
    I figured out how to copy a file to a specified location on the filesystem of the master hudson server using a maven plugin, however I am running into problems copying that file down to the slaves. I't like to copy the rule file to /tmp/minimalRules.txt but the "Copy to Slave" hudson plugin only puts the files into the root of $WORKSPACE. It doesn't look like this plugin supports reading environment variables so that doesn't help.

  7. Aug 30, 2010

    KT Kirk says:

    Is there away to get it to work with an external job?

    Is there away to get it to work with an external job?

  8. Sep 26, 2010

    Tomáš Homola says:

    Hi all, nice plugin but Is there way how to mark more lines by some regex patte...

    Hi all, nice plugin but Is there way how to mark more lines by some regex pattern(s)?? For example mark this lines of console output as error

    [javac] Compiling 720 source files to /home/prcek/java_aisservis/GolemEJB/build/jar
    [javac] /home/prcek/java_aisservis/GolemEJB/src/java/cz/aisservis/ejb/golem/utils/BeanMapper.java:4: ';' expected
    [javac] package cz.aisservis.ejb.golem.utils
    [javac] ^
    [javac] 1 error

    I have done it to modify plugin by myself but I will(I hope others as well) appreciate if it will in official release.

    Thanks Tomas

    1. Dec 06, 2010

      John Borghi says:

      Hi Tomas, I'm not sure I follow. Is the change to mark and treat a group of lin...

      Hi Tomas,
      I'm not sure I follow. Is the change to mark and treat a group of lines as a single error? Do you have a patch for this? It indeed sounds very useful!

  9. Dec 01, 2010

    Ajay Kumar says:

    I am seeing garbage characters (Hex characters) when the "Add timestamps" is sel...

    I am seeing garbage characters (Hex characters) when the "Add timestamps" is selected in Job configure. Can anyone help me to overcome this issue or this is a bug in plugin?. Thanks in advance.

    Here is how the output looks

    ha:AAAAdB+LCAAAAAAAAABb85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgZGLwaB3MycnMzi4My85FTXgvzkjIoiBimoScn5ecX5Oal6zhAaVS9DRQGQ1lnw9KIYADxiu4CBAAAA Submitting files for "Source" perforce...
    ha:AAAAdB+LCAAAAAAAAABb85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgZGLwaB3MycnMzi4My85FTXgvzkjIoiBimoScn5ecX5Oal6zhAaVS9DRQGQ1lnw9NokAMKzLyWBAAAA Warning: No files to submit for "Source"

    Should be like this
    23:46:44 Submitting files for "Source" perforce...
    23:46:46 Warning: No files to submit for "Source"

    1. Dec 06, 2010

      John Borghi says:

      Hi Ajay, This was reported in HUDSON-7263. There is a patch attached to the bug...

      Hi Ajay,
      This was reported in HUDSON-7263. There is a patch attached to the bug, and a release should be coming out shortly that will address this problem.

      1. Dec 08, 2010

        Sam Wrankmore says:

        John, is there a planned release date yet? I would like to use both this and th...

        John, is there a planned release date yet? I would like to use both this and the timestamper plugin but at present it confuses the user.

        1. Dec 08, 2010

          John Borghi says:

          Hi Sam, It is pretty ugly! The fix should be out in the next few days. It woul...

          Hi Sam,
          It is pretty ugly! The fix should be out in the next few days. It would be easy to strip out the console notes (timestamps) but I am trying to see if they can be preserved in the parsed output.

  10. Dec 09, 2010

    Sam Wrankmore says:

    A couple of other queries/suggestions. (Some may already be possible - if so, pl...

    A couple of other queries/suggestions. (Some may already be possible - if so, please let me know)

    The first is cosmetic (but would stop distraction): Is it possible to configure the format of colours and fonts used? The orange on white for warnings is difficult to read, and the use of a non-uniformly-spaced font makes scanning the output cumbersome.

    Re-parsing of logs: I would like to be able to modify the parser used and 'reparse' an existing log. There are times when you may find a false-positive, wish to change the parser or use a more verbose parser on the same log without having to re-run the build job.

    Section grouping: Allow the expansion and reduction of lines for identified sections, similar to the top-level 'Error', 'Info' and 'Warning'. There are times where we have several hundred warnings or info messages and another level in the 'tree' would simplify their review.

    Thoughts/comments gratefully received.

    1. Dec 14, 2010

      John Borghi says:

      Hi Sam, Thank you for the suggestions. None are currently available... 1. Cust...

      Hi Sam,

      Thank you for the suggestions. None are currently available...

      1. Custom colors/fonts. Color should be straightforward. The report was supposed to use the standard Hudson css so as to keep a consistent look and feel, but due to bug HUDSON-8268, it was not always finding the style sheet. But this still isn't a fixed width font. Maybe a configuration option to wrap the whole report in a <pre> block, similar to the console text output would suffice?

      2. Re-parsing has been considered, but presents some problems. The log parsing can set the build status. It is generally not a good practice to modify the build result manually (which essentially this feature would do) after a build is complete, so we did not pursue this. Automation steps are often based on build status, so manually changing it "after the fact" introduces new complexities. I also believe the Hudson core prevents this by:
      a.) Only allowing the build status to be set while the build is running.
      b.) The status can only be set to a 'lower' level. Presumably since later steps might be run but not know the build is already unstable/failed, it wouldn't be good to upgrade the result.

      3. You mean to have any build 'sections' also be a collapsible tree? Seems quite reasonable.

      Thanks!

  11. Feb 11, 2011

    Paul Walmsley says:

    Thanks for the Plugin -- it's hugely useful (especially with Xcode build...

    Thanks for the Plugin -- it's hugely useful (especially with Xcode builds which are very verbose and hard to spot errors in).  It's taken me a while to work out exactly how to get this running, because of the quirks in the way the path to the rules file is stored in the jobs, so for the benefit of other users here's how I got it running (the order of these steps is significant):

    • Create a rules file on the hudson server
    • Configure the hudson server (as in the Global Configuration section above), with the absolute path to where the rules file lives on the server
    • Configure a job to use the log parser (as in the Job Configuration section above).  In the current version this will copy the location of the rules file into the job config.xml, so if you change the location of the rules file you will have to update the job scripts in a text editor
  12. Feb 26, 2011

    Raghuram Arakalgud says:

    Hi, Thanks for this wonderful plugin. This plugin seems to be incompatible with...

    Hi,
    Thanks for this wonderful plugin.

    This plugin seems to be incompatible with java 1.5. I get this error when using on 1.5.
    From the java docs, String supports isEmpty() only from 1.6 http://download.oracle.com/javase/6/docs/api/java/lang/String.html#isEmpty()

    Can you pls make it compatible with 1.5?

    16:09:50 FATAL: java/lang/String.isEmpty()Z
    16:09:50 java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z
    16:09:50 at hudson.plugins.logparser.CompiledPatterns.setError(CompiledPatterns.java:18)
    16:09:50 at hudson.plugins.logparser.LogParserUtils.compilePatterns(LogParserUtils.java:103)
    16:09:50 at hudson.plugins.logparser.LogParserParser.<init>(LogParserParser.java:56)
    16:09:50 at hudson.plugins.logparser.LogParserPublisher.perform(LogParserPublisher.java:52)
    16:09:50 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
    16:09:50 at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:603)
    16:09:50 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:582)
    16:09:50 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:560)
    16:09:50 at hudson.model.Build$RunnerImpl.post2(Build.java:156)
    16:09:50 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:529)
    16:09:50 at hudson.model.Run.run(Run.java:1361)
    16:09:50 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    16:09:50 at hudson.model.ResourceController.execute(ResourceController.java:88)
    16:09:50 at hudson.model.Executor.run(Executor.java:140)

    1. Apr 11, 2011

      John Borghi says:

      Opened the issue at https://issues.jenkins-ci.org/browse/JENKINS-9316
  13. Mar 15, 2011

    palatoss says:

    This plugin doesn't work anymore with Hudson 1.398. "Console Output Parsing" men...

    This plugin doesn't work anymore with Hudson 1.398. "Console Output Parsing" menu doesn't appear on the System and Job Configuration Menus. It did work in Hudson 1.396.

    1. Apr 12, 2011

      Susan Duncan says:

      The plugin should re-appear if you set this JVM&nb...

      The plugin should re-appear if you set this JVM property on startup:
         "-Dhudson.PluginStrategy=hudson.ClassicPluginStrategy"

      In 1.398 we implemented a new JSR330 compatible PluginStrategy enabled by default, so developers could try it out and report 
      any incompatibilities which weren't picked up by the current integration tests. You have come across one of those incompatibilities. I have raised an issue on this plugin. You can read more about the integration strategy here:

      http://java.net/projects/hudson/lists/dev/archive/2011-04/message/13

      logged issue:  http://issues.hudson-ci.org/browse/HUDSON-8812

  14. Apr 11, 2011

    Miles Duke says:

    This is a great plugin. It's amazing how long we trolled through our 200K+ l...

    This is a great plugin. It's amazing how long we trolled through our 200K+ line log files before. Of course, log files this large do stress some browsers beyond the breaking point, particularly when you try to navigate to a specific message. They don't crash, but they can become unresponsive.

    My key feedback, though, is that the scanners seem to be case-sensitive. Thus, in order to get all of the interesting messages, I am trying expressions like this:

    error /\[Ee\]\[Rr\]\[Rr\]\[Oo\]\[Rr\]/
    
    

    Is there a way to mark the regular expression as being case-insensitive?

    1. Apr 11, 2011

      John Borghi says:

      You can get case-insensitive matches using the Java embedded flag notation. To g...

      You can get case-insensitive matches using the Java embedded flag notation. To get case-insensitive matching for the string 'error', the pattern would be

      error /(?i)error/

      I will add a note to the docs.