-
New Feature
-
Resolution: Fixed
-
Minor
-
None
The idea comes from that we have came cross the problems that when use a third party script/tool, sometime it's pretty hard to change the script/tool to display full path in console output, or the relative path towards jenkins workspace(or me being lame..).
Thanks to https://issues.jenkins-ci.org/browse/JENKINS-32150, now it's possible to Resolve relative paths.
If I understand it correctly, the warnings plugin resolve the path gotten from console output relative to Jenkins workspace. The warning displayed below has a real path "$JENKINS_HOME/[job-name]/workspace/AA/BB/CC/Mew/NNN/src/NNW.c", but log displays:
"..\Mew\NNN\src\NNW.c", line 11: warning #200-D: function ----------
Error message:
Copying the source file './Mew/NNN/src/NNW.c"' from the workspace to the build folder '36d4bd99.tmp' on the Jenkins master failed. Seems that the path is relative, however an absolute path is required when copying the sources. Is the file 'NNW.c"' contained more than once in your workspace? Is the file './Mew/NNN/src/NNW.c"' a valid filename? If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/[job-name]/./Mew/NNN/src/NNW.c"' If you are building on the master: please check if the file is accessible under '$JENKINS_HOME/[job-name]/workspace/./Mew/NNN/src/NNW.c"' java.io.IOException: Failed to copy Mew/NNN/src/NNW.c" to /home/jobs/TEST_build/builds/10/workspace-files/36d4bd99.tmp at hudson.FilePath.copyTo(FilePath.java:1984) at hudson.plugins.analysis.util.Files.copyFilesWithAnnotationsToBuildFolder(Files.java:80) at hudson.plugins.analysis.core.HealthAwareRecorder.copyFilesWithAnnotationsToBuildFolder(HealthAwareRecorder.java:351) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:91) at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:298) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78) .............
Is possible to add a feature that the plugin could search the source file not only in relative to Jenkins default workspace only, but also other path? Thanks a lot! Hopefully I am not alone with the problem here.
- is blocking
-
JENKINS-55998 recordIssues cannot see /workspace within docker.image.inside
-
- Resolved
-
-
-
- Resolved
-
- is duplicated by
-
-
- Closed
-
[JENKINS-48802] Possibility to add/change the path that used to display source files
Li Liu
created issue -
| Component/s | New: warnings-ng-plugin [ 24526 ] | |
| Component/s | Original: warnings-plugin [ 15513 ] |
| Link |
New:
This issue is blocking |
| Link |
New:
This issue is blocking |
| Rank | New: Ranked higher |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Matthieu Brucher
added a comment - I have a similar issue. I generate a checkstyle file inside a docker container with some paths, but using relative paths there makes the upload break later due to Warnings NG not capable of reconciling the files.
Matthieu Brucher
added a comment - I have a similar issue. I generate a checkstyle file inside a docker container with some paths, but using relative paths there makes the upload break later due to Warnings NG not capable of reconciling the files. How do you invoke CheckStyle? CheckStyle normally does export absolute paths already.
Matthieu Brucher
added a comment - The file is generated from eslint inside a docker container. As such the paths will be different than the ones from the workspace (not even talking about the fact that there are several containers in flight, each of them having only a part of the workspace).
Matthieu Brucher
added a comment - The file is generated from eslint inside a docker container. As such the paths will be different than the ones from the workspace (not even talking about the fact that there are several containers in flight, each of them having only a part of the workspace).
As a additional add to this request, can the possible path prefixes to check be a collection? For example, The TagList parser reports hits in source files, without indicating if they in the main directory or the test directory, and letting the file name resolution part look in many spots would be useful to solving this issue.