-
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
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). Hmm, but how should adding a source code path help in your case? The files are fetched from the agent that contains the checkstyle.xml file. Is your workspace outside of the docker container? And how does eslint find the sources to check?
Matthieu Brucher
added a comment - eslint is run inside the container, the container itself is built at the beginning of the pipeline. As I can't assume that the Jenkins slave have all the required tools to run eslint, the proper way to go was to use a container that would retrieve the required modules.
Just adding a way to reconnect the two paths would be enough, as the path inside the container (also used for the unit tests) is just a fraction of the actual workspace path. Basically just adding "folder/" as "folder" would be where I built the container. The Jenkins pipeline itself is run in the parent of "folder", I suspect that's why the checker cannot figure out where the files actually are.
Matthieu Brucher
added a comment - eslint is run inside the container, the container itself is built at the beginning of the pipeline. As I can't assume that the Jenkins slave have all the required tools to run eslint, the proper way to go was to use a container that would retrieve the required modules.
Just adding a way to reconnect the two paths would be enough, as the path inside the container (also used for the unit tests) is just a fraction of the actual workspace path. Basically just adding "folder/" as "folder" would be where I built the container. The Jenkins pipeline itself is run in the parent of "folder", I suspect that's why the checker cannot figure out where the files actually are. 
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.