-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins ver. 2.138.3 (Docker Hub)
Wanings NG 1.0.0-beta5
-
-
warnings-ng 1.0.1
The configuration and functionality is currently lacking
1) The help text under the Static Analysis Tool configuration (Freestyle job), should add that the own configured Parser can be found if "Groovy Parser" is selected
For each static analysis tool a dedicated parser will be used to read the report files. If your tool is not yet supported then you can create your own parser in the system configuration.
2) Groovy Parser cant scan console log output ?!
Seems a bit weird to me that a single scanner has this limitation, is this getting fixed, or is there a recommendation to start writing logs to a file first? (As in best practices, generally for Jenkins or specific to this plugin). like using "2>&1 | tee some.log" on commands?
FATAL: Static analysis tool Groovy Parser cannot scan console log output, please define a file pattern
[JENKINS-54759] Groovy Parsers - improve help text
Norbert Lange
added a comment - Scanning of the console log is done on the master currently, all other files are scanned on the agent....Do you have a better idea?
I would try to move all processing to the agent(s), its not obvious to me why this split exists (has to exist).
Can’t you pipe your log output to a file on the agent?
Yes I can, but not without issues. Some variants:
- not piping would be the most clear, and similar to the scripts you would run on a local build
- piping it just to a file will remove all visible status during execution
- naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here
- additionally storing and restoring the errors state of the script adds boilerplate code
That's why I asked about a recommendation (a bug tracker is the wrong place, but you don't have a forum?)
As for the split, keep the help-text issue here, and handle the rest in JENKINS-52237?
Norbert Lange
added a comment -
Scanning of the console log is done on the master currently, all other files are scanned on the agent....Do you have a better idea?
I would try to move all processing to the agent(s), its not obvious to me why this split exists (has to exist).
Can’t you pipe your log output to a file on the agent?
Yes I can, but not without issues. Some variants:
not piping would be the most clear, and similar to the scripts you would run on a local build
piping it just to a file will remove all visible status during execution
naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here
additionally storing and restoring the errors state of the script adds boilerplate code
That's why I asked about a recommendation (a bug tracker is the wrong place, but you don't have a forum?)
As for the split, keep the help-text issue here, and handle the rest in JENKINS-52237 ? Actually a new issue would be better, these are somewhat opposite requests. Then we see if JENKINS-52237 or scanning the console log with Groovy should be implemented first.
Can you please split this issue so that I can track the progress individually?
The second point is related to JENKINS-52237. Scanning of the console log is done on the master currently, all other files are scanned on the agent. On the master a Groovy script could do harmful things. If I allow a parser script configuration in a job this might be too dangerous. So I thought it would be better to disable processing of Groovy scripts on the master. Do you have a better idea?
Can’t you pipe your log output to a file on the agent?