-
New Feature
-
Resolution: Fixed
-
Minor
-
None
Disclaimer: I have already posted this issue as a question on Stackoverflow, but unfortunately got no feedback there.
Unfortunately, although the warnings are collected and displayed, I cannot trace them back to the source code. The overview shows the correct file path and the file still exists in the file system after the build.
When I click on the file to investigate the individual issues, the filename and line are displayed, but I can't click on it to look at the location in the code.
According to the plugin's documentation, warnings should actually also be displayed in the code if they affect a specific line, for example.
I'm using the iar and the iarCstat plugin like this:
success {
dir("${BUILD_DIR}") {
recordIssues(
tools: [
iar(),
iarCstat(pattern: "${BUILD_DIR}\\cstat\\cstat_log.txt")
]
)
}
}
Can anyone tell me if I am using the plugin incorrectly or if this problem is known? I could not find anything about it...
- is blocked by
-
JENKINS-66810 Use case insensitive matching on Windows
-
- Open
-
- links to
[JENKINS-66687] Warnings not showed in file when case insensitive path is provided
Since all windows versions have case-insensitive file paths, i'd suggest number 3. icstat probably isn't the first and won't be the last software on windows that messes up paths... 
Is there a "quick hack" that can prove that this is indeed the problem?
You can pipe the output of icstat to a file and replace the paths with the correct one before the warnings plugin runs.
Uff, this is easy on linux but on windows?... Give me some hours/days 
Unfortunately, I have not yet found the time to try it out. Do you already have an idea how the problem could be solved in the long term?
A colleague of mine has found a solution to the problem. However, not the cstat database is used but only the log output. I am not quite sure if information is lost there.
cstat must be run in the project root (not in the build directory) and recordIssues must be run in the build directory. Then it works
Ok good to hear! I created a followup issue JENKINS-66810 so I can change the current behavior in the future (I don't have spare time right now).
Is this still a problem? I think the preprocessing has been changed to use real paths recently. Please reopen if still valid.
I see three solutions: