-
Bug
-
Resolution: Fixed
-
Trivial
-
Jenkins v2.190.1
Warnings-NG v6.1.1
wsbt test run fails in Jenkins build, producing a line such as:
[error] Total time: 127 s, completed Oct 7, 2019 9:11:30 AM
Later, during
post { always { recordIssues enabledForFailure: true, tools: [scala()] } }
the following output occurs in Jenkins log:
[Scala Compiler] [-ERROR-] Can't resolve absolute paths for some files: [Scala Compiler] [-ERROR-] - Total time: 127 s, completed Oct 7, 2019 9 [Scala Compiler] [-ERROR-] Can't create fingerprints for some files: [Scala Compiler] [-ERROR-] - 'Total time: 127 s, completed Oct 7, 2019 9', IO exception has been thrown: java.nio.file.NoSuchFileException: Total time: 127 s, completed Oct 7, 2019 9
Looks like a false positive from [Sbt]ScalacParser regex capture at first glance:
Not a big deal at all, but can be confusing (in particular since scalac ran green).
[JENKINS-59865] Bogus Scala Compiler warning about missing files after test failure in sbt
Are you saying that the sbt should not be throwing an error as scalac ran green or are you saying that scalac parser is not recognizing the error?
I think the issue is about the Scala parser: it should ignore the error message with the summary line and the runtimes.
Hi drulli, I am a classmate of Benjamin Cross and we are working on the bug together. I have been working through it and have a good idea about what is going on but was wondering if I could ask a few questions about recreating the bug before attempting to resolve it. Presently, I understand that the ScalacParser sbt parser is a class of the analysis-model which is a jar that is employed by the plugin Jenkins-Next-Generation-Warning. In trying to recreate it, the thought we had was to create a Scala project which, when running along with the pipeline including 'post { always
}' and having the above plugin enabled to record the issues, it would produce the issue as explained above. From there, we would validate the results before making proper changes to regEx to exclude the false positive line. I had to present this work approach, so I put together a brief diagram - below.
Questions I have:
- does this understanding sound right?
in creating the sample scala project to recreate this, I think we should compile with the scalac as this parser deals with it , is that right?Upon more investigation, this is with sbt, not scalac so that was wrong- Are there any other resources that I should look to?
My apologies if these questions are all very introductory, we are still getting a handle of understanding the project
thanks and happy holidays
-Jarred Parrett
Jarred Parrett
added a comment - - edited Hi drulli , I am a classmate of Benjamin Cross and we are working on the bug together. I have been working through it and have a good idea about what is going on but was wondering if I could ask a few questions about recreating the bug before attempting to resolve it. Presently, I understand that the ScalacParser sbt parser is a class of the analysis-model which is a jar that is employed by the plugin Jenkins-Next-Generation-Warning. In trying to recreate it, the thought we had was to create a Scala project which, when running along with the pipeline including 'post { always
{ recordIssues enabledForFailure: true, tools: [scala()] }
}' and having the above plugin enabled to record the issues, it would produce the issue as explained above. From there, we would validate the results before making proper changes to regEx to exclude the false positive line. I had to present this work approach, so I put together a brief diagram - below.
Questions I have:
does this understanding sound right?
in creating the sample scala project to recreate this, I think we should compile with the scalac as this parser deals with it , is that right? Upon more investigation, this is with sbt, not scalac so that was wrong
Are there any other resources that I should look to?
My apologies if these questions are all very introductory, we are still getting a handle of understanding the project
thanks and happy holidays
-Jarred Parrett
I think it is much simpler to reproduce and fix this bug. You only need to change and test the analysis model module. Create a text file that contains the message from above (with the error) and read it in the test class SbcParserTest with the parser SbcParser. It should produce a warning. Then fix the bug so that no warning will be shown anymore.
There is no need to use the warnings-ng plugin for the test, as the bug is only part of the library analysis-model.
Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement -
"^(\\[warn\\]|\\[error\\](?!\\s+Total\\stime:))\\s*(.*?):(\\d+)(?::\\d+)?:\\s*(.*)$"
Thank you for your help
Jarred Parrett
added a comment - - edited Thank you for the direction - it made it much easier to recreate. In working on it, I think its test class was SbtScalacParserTest.java; I ran that with a custom text file that contained the content from sbtScalac.txt with the addition of the above line. The test then fails as it expects 4 errors in the report but gets 5. To resolve this, I changed the SbtScalacParser.java to include the negative lookahead statement -
"^(\\[warn\\]|\\[error\\](?!\\s+Total\\stime:))\\s*(.*?):(\\d+)(?::\\d+)?:\\s*(.*)$"
Thank you for your help 
Perfectly looks like a Hacktoberfest candidate.