[JIRA] (JENKINS-61384) warnings-ng plugin doesn't copy files from workspace if source directory is given

19 views
Skip to first unread message

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 8, 2020, 10:37:03 AM3/8/20
to jenkinsc...@googlegroups.com
Juergen Lorenz created an issue
 
Jenkins / Bug JENKINS-61384
warnings-ng plugin doesn't copy files from workspace if source directory is given
Issue Type: Bug Bug
Assignee: Ulli Hafner
Components: warnings-ng-plugin
Created: 2020-03-08 14:36
Priority: Minor Minor
Reporter: Juergen Lorenz

If the source directory is given in the configuration a job (and also in the configuration of the warnings-ng plugin), there are no copies of files from the workspace. Copies from the workspace are made only when the source directory left empty.
In the documentation the source directory is described as "additonal" directory, but this seems wrong.

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 8, 2020, 10:38:02 AM3/8/20
to jenkinsc...@googlegroups.com
Juergen Lorenz updated an issue
Change By: Juergen Lorenz
Environment: Jenkins ver. 2.204.2
Warnings Next Generation Plugin 8.0.0

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 8, 2020, 10:48:02 AM3/8/20
to jenkinsc...@googlegroups.com
Juergen Lorenz commented on Bug JENKINS-61384
 
Re: warnings-ng plugin doesn't copy files from workspace if source directory is given

I see, that a new version 8.1.0 of the plugin is available. But if I read the javacode of the plugin, it seems that the bug is still there.

In IssuesScanner.java I can find:

    private void copyAffectedFiles(final Report report, final FilePath buildFolder)
            throws InterruptedException {
        report.logInfo("Copying affected files to Jenkins' build folder '%s'", buildFolder);

        new AffectedFilesResolver().copyAffectedFilesToBuildFolder(
                report, buildFolder, getPermittedSourceDirectory(report));
    }

The call to "getPermittedSourceDirectory(report)" gives the source directory of the configuration of the job (with the permission proof of the configuration of the warnings-ng plugin) or the workspace.
The AffectedFilesResolver could get the workspace as an additional parameter (its a member of IssuesScanner) and then the check in AffectedFilesResolver.RemoteFacade can advanced: isInWorkspace + isInSourceDirectory.

ullrich.hafner@gmail.com (JIRA)

unread,
Mar 8, 2020, 3:01:02 PM3/8/20
to jenkinsc...@googlegroups.com

Yes, I changed the behavior since now the root folder of the source code is set as a property of every report. This requires a new unique name. Do you have multiple roots in one warning report? Or why do you specify the source folder if it is not used?

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 10, 2020, 4:31:04 AM3/10/20
to jenkinsc...@googlegroups.com
Juergen Lorenz updated an issue
Change By: Juergen Lorenz
Environment: Jenkins ver. 2.204. 2 4
Warnings Next Generation Plugin 8.0.0

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 10, 2020, 5:07:02 AM3/10/20
to jenkinsc...@googlegroups.com
Juergen Lorenz commented on Bug JENKINS-61384
 
Re: warnings-ng plugin doesn't copy files from workspace if source directory is given

Our programming language is C++ und we have several pre-build libraries with header files at a distinct server.
In the build process we include this header files and the linker use the pre-build libs.

Some cppcheck messages refer to this header files. This messages will not shown, when the library was build itself (in a other project), because it will be find by the cppcheck only when the class is used. So I have 2 roots: the workspace of the project and the folder of the pre-build lib.

If I give the source directory in the configuration (the common folder of all pre-build libs), the plugin will only copy the header files of the pre-build libs.
If I let the source directory empty, the plugin will only copy the header and source files from the project.

ullrich.hafner@gmail.com (JIRA)

unread,
Mar 10, 2020, 6:28:02 AM3/10/20
to jenkinsc...@googlegroups.com

I see. Currently I do not see a way how this could be achieved with the new version of the plugin (without relocating the files in question to the same root).

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 10, 2020, 12:55:02 PM3/10/20
to jenkinsc...@googlegroups.com

Relocating the files in question to the same root is not so easy, I'm afraid.
I'm only had a look in IssuesScanner and see a easy way to solve this problem. If you give the folder as a property of the report, then it wouldn't be possible to have multiple roots.

Thanks.

ullrich.hafner@gmail.com (JIRA)

unread,
Mar 10, 2020, 2:54:03 PM3/10/20
to jenkinsc...@googlegroups.com

I'm not sure if I can follow your argumentation, or if I miss something obvious. Affected files of the warnings are now stored using the relative path per issue and a global path prefix from the report. Every access to the file (fingerprint, affected files, etc.) is now using the absolute path of the issue (issue.getAbsolutePath()).

ullrich.hafner@gmail.com (JIRA)

unread,
Mar 10, 2020, 2:55:02 PM3/10/20
to jenkinsc...@googlegroups.com
Ulli Hafner edited a comment on Bug JENKINS-61384
I'm not sure if I can follow your argumentation, or if I miss something obvious. Affected files of the warnings are now stored using the relative path per issue and a global path prefix from the report. Every access to the file (fingerprint, affected files, etc.) is now using the absolute path of the issue ({{issue.getAbsolutePath()}}). Or what exactly is returned in your case for this header files? Maybe we should use an actual example of those files in order to solve the problem...

juergen.lorenz@kabelmail.de (JIRA)

unread,
Mar 16, 2020, 6:39:02 AM3/16/20
to jenkinsc...@googlegroups.com

Sorry for the late answer. I will try to explain how we use the cppcheck and the plugin.

In our call to the cppcheck, we go (via makefile) to the folder "source" and give only the filenames and the directories of the include's as arguments.
So the xml-file contains the filename for files in the folder "source", absolute paths for headers in the include folder of the project and absolute paths for headers in the include folder of other libraries (at a server).
Before we use your warnings-ng plugin, we use cppcheck plugin to publish the results. Because this plugin need it (maybe in an old version), we add the absolute path to the filenames via a perl script. So we had absolute paths for all files.
In the warnings-ng plugin I saw as tooltip the subfolders (under the workspace dir), if the extra soure directory was left empty. And the subfolders under the common root, if the extra soure directory was set to this common root.

But I find a way to copy the files, as you suggest. And it works fine.
So, if nobody else need the multiple roots (and maybe I misunderstand how this works), we can close this JIRA.

ullrich.hafner@gmail.com (JIRA)

unread,
Mar 17, 2020, 5:04:06 AM3/17/20
to jenkinsc...@googlegroups.com
Ulli Hafner resolved as Won't Fix
 

Ok: I hope that your use case is some kind of exception. If someone else requires more root folders (during one recordIssues step call) we can reopen this issue again and think on how to implement that.

Change By: Ulli Hafner
Status: Open Resolved
Resolution: Won't Fix
Reply all
Reply to author
Forward
0 new messages