-
Improvement
-
Resolution: Won't Fix
-
Minor
-
None
In using the log parser, I have had amusing false negatives and false positives.
I would be very helpful if there was a setting that created a log file showing the log file being applied, the rule being applied and the associated log file line.
for example: (log_parser_debug_log_<project_name>build<build_number>.txt)
Rule File: log_parsing_rules.txt
error\t14\t345\tSomething bad happened to generate a fatal error.
where
- error is the label being applied
- 14 is the line of the rules file
- 345 is the line of the log being parsed
- the remaining text is the line from the log
Additionally, being able to specify the separator string (shown here as a tab) would be helpful.
[JENKINS-9568] log parser should be able to generate a log indicating which rule was applied
| Description |
Original:
In using the log parser, I have had amusing false negatives and false positives. I would be very helpful if there was a setting that created a log file showing the log file being applied, the rule being applied and the associated log file line. for example: (log_parser_debug_log_<project_name>_build_<build_number>.txt) Rule File: log_parsing_rules.txt error\t14\t345\tSomething bad happened to generate a fatal error. Additionally, being able to specify the separator string (shown here as a tab) would be helpful. |
New:
In using the log parser, I have had amusing false negatives and false positives. I would be very helpful if there was a setting that created a log file showing the log file being applied, the rule being applied and the associated log file line. for example: (log_parser_debug_log_<project_name>_build_<build_number>.txt) Rule File: log_parsing_rules.txt error\t14\t345\tSomething bad happened to generate a fatal error. where - error is the label being applied - 14 is the line of the rules file - 345 is the line of the log being parsed - the remaining text is the line from the log Additionally, being able to specify the separator string (shown here as a tab) would be helpful. |
John Muczynski
added a comment - Here we go, I have found a possibility for debugging. I'm motivated because my jobs take 1-hr to 7-hrs to run and I'd like to re-parse rules without waiting.
Here's the idea. I have installed the Promoted Builds plug-in. During promotion, you can configure it to do a build step: for example, run the console log parser. Also, a promotion can be manual – which means you click in a web page to cause the promotion. Finally, a promotion can be repeated.
Put all three of these together and this means that I'm going to try to run the console log parser on demand. I should be able to update the rules file on the Jenkins server. I may have to Ant-echo a file to give the parser something interesting to parse. I'm hoping it uses the old console log, but I'm realizing as I write this that it will probably use the console log from the promotion execution.
John Muczynski
added a comment - Here we go, I have found a possibility for debugging. I'm motivated because my jobs take 1-hr to 7-hrs to run and I'd like to re-parse rules without waiting.
Here's the idea. I have installed the Promoted Builds plug-in. During promotion, you can configure it to do a build step: for example, run the console log parser. Also, a promotion can be manual – which means you click in a web page to cause the promotion. Finally, a promotion can be repeated.
Put all three of these together and this means that I'm going to try to run the console log parser on demand. I should be able to update the rules file on the Jenkins server. I may have to Ant-echo a file to give the parser something interesting to parse. I'm hoping it uses the old console log, but I'm realizing as I write this that it will probably use the console log from the promotion execution.
John Muczynski
added a comment - Eh, nope. That didn't work. The parser runs, but I don't know where the output got stored. No sense in tracking down what input its using if I can't see the output 
Sounds like the next best thing would be to set up a dummy job that does an Ant <echo> of an old log so that the parser can parse it. That's a bit of fussing around just to debug some rules. I guess I'll just plan to tweak the rules once a day until they're all settled.
John Muczynski
added a comment - Eh, nope. That didn't work. The parser runs, but I don't know where the output got stored. No sense in tracking down what input its using if I can't see the output
Sounds like the next best thing would be to set up a dummy job that does an Ant <echo> of an old log so that the parser can parse it. That's a bit of fussing around just to debug some rules. I guess I'll just plan to tweak the rules once a day until they're all settled.
| Workflow | Original: JNJira [ 139736 ] | New: JNJira + In-Review [ 175141 ] |
| Resolution | New: Won't Fix [ 2 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
Can I run the log parser's parser outside of Jenkins
and hand it a console log
and step through its rule matching?
Is there an easy way to hack the source code to do this?