We are using the warnings-ng plugin to analyze some of our projects with the following code

      recordIssues enabledForFailure: true, blameDisabled: true,tools: [java(), mavenConsole(), taskScanner(highTags: 'FIXME', normalTags: 'TODO, CHECKSTYLE IGNORE')]
      

      This leads to very large folders on the Jenkins master (around 250MB for a single build) compared to the old Static Analysis Plugin.

      An option to disable this behaviour or to specify retention times separatly from build retention times would be appreciated.

          [JENKINS-58167] Add option to not store affected files

          Ulli Hafner added a comment -

          Ah ok, thanks for clarifying. That would be easier to implement.

          Ulli Hafner added a comment - Ah ok, thanks for clarifying. That would be easier to implement.

          I feel the source code URLs should be generated by RepositoryBrowser (javadoc) implementations, because those already need to know about the URL format of the software that serves the files to Web browsers. Whether that is a version-control system like GitHub or separate code-review software.

          If Jenkins built a pull request merge, then it may be impossible to generate URLs for the merged files. Even if the code-review software supports such URLs, it might not merge the versions in exactly the same way. The RepositoryBrowser implementation should be told about the merge so that it can decide whether it wants to try constructing a URL or just give up.

          SCMRevision (javadoc) seems the obvious type to use for this, as you could then use ChangeRequestSCMRevision (javadoc) to represent the merge. However, these types are in scm-api-plugin while RepositoryBrowser is in core, so one cannot just add an Optional<URL> getFileLineLink(SCMRevision revision, String path, int startLine, int endLine) method to RepositoryBrowser. Instead, scm-api-plugin could define an interface with such a method, and individual RepositoryBrowser implementations could then implement that interface.

          Kalle Niemitalo added a comment - I feel the source code URLs should be generated by RepositoryBrowser ( javadoc ) implementations, because those already need to know about the URL format of the software that serves the files to Web browsers. Whether that is a version-control system like GitHub or separate code-review software. If Jenkins built a pull request merge, then it may be impossible to generate URLs for the merged files. Even if the code-review software supports such URLs, it might not merge the versions in exactly the same way. The RepositoryBrowser implementation should be told about the merge so that it can decide whether it wants to try constructing a URL or just give up. SCMRevision ( javadoc ) seems the obvious type to use for this, as you could then use ChangeRequestSCMRevision ( javadoc ) to represent the merge. However, these types are in scm-api-plugin while RepositoryBrowser is in core, so one cannot just add an Optional<URL> getFileLineLink(SCMRevision revision, String path, int startLine, int endLine) method to RepositoryBrowser. Instead, scm-api-plugin could define an interface with such a method, and individual RepositoryBrowser implementations could then implement that interface.

          Ulli Hafner added a comment -

          The SCM API does not really provide a good API for such use cases. A couple of weeks ago I failed to add simple hyperlinks to Git commits in my plugin, so I needed to extend the Git plugin. The same needs to be done here...

          Ulli Hafner added a comment - The SCM API does not really provide a good API for such use cases. A couple of weeks ago I failed to add simple hyperlinks to Git commits in my plugin, so I needed to extend the Git plugin. The same needs to be done here...

          I guess you mean https://github.com/jenkinsci/git-plugin/pull/1034 and https://github.com/jenkinsci/git-forensics-plugin/pull/241. For the source line links though, I don't think the API should be specific to Git. There are RepositoryBrowser implementations for other version-control systems, and at least some of them could implement the source line link API.

          For example, the RhodeCode software apparently supports https://try.rhodecode.com/ci-notify/files/3ad87bf0c7e571c685989e843936f16e945a899c/notify.py#L6 in a Mercurial repository. https://try.rhodecode.com/ci-notify/files/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md however seems problematic because it renders the Markdown to HTML and does not output anchors for line numbers. https://try.rhodecode.com/ci-notify/raw/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md outputs the original Markdown but that's text/plain and so has no anchors at all. Perhaps the hyperlink would have to use https://try.rhodecode.com/ci-notify/annotate/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md.

          Kalle Niemitalo added a comment - I guess you mean https://github.com/jenkinsci/git-plugin/pull/1034 and https://github.com/jenkinsci/git-forensics-plugin/pull/241 . For the source line links though, I don't think the API should be specific to Git. There are RepositoryBrowser implementations for other version-control systems, and at least some of them could implement the source line link API. For example, the RhodeCode software apparently supports https://try.rhodecode.com/ci-notify/files/3ad87bf0c7e571c685989e843936f16e945a899c/notify.py#L6 in a Mercurial repository. https://try.rhodecode.com/ci-notify/files/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md however seems problematic because it renders the Markdown to HTML and does not output anchors for line numbers. https://try.rhodecode.com/ci-notify/raw/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md outputs the original Markdown but that's text/plain and so has no anchors at all. Perhaps the hyperlink would have to use https://try.rhodecode.com/ci-notify/annotate/9d541eb7ff6e840ca2618ba63f4e0e17ff901808/readme.md .

          My scenario is that we have binary files in version control (using Git LFS), and build steps sometimes output warnings about these files. In such cases, Warnings NG copies the files to the controller and displays them as text, which is not helpful at all. The Jenkinsfile in that project might be considered a bit incorrect, as it specifies sourceCodeEncoding: 'UTF-8' in the recordIssues step and that then applies to the binary files too; but well, there is no option to exclude file patterns from this encoding claim.

          Kalle Niemitalo added a comment - My scenario is that we have binary files in version control (using Git LFS), and build steps sometimes output warnings about these files. In such cases, Warnings NG copies the files to the controller and displays them as text, which is not helpful at all. The Jenkinsfile in that project might be considered a bit incorrect, as it specifies sourceCodeEncoding: 'UTF-8' in the recordIssues step and that then applies to the binary files too; but well, there is no option to exclude file patterns from this encoding claim.

          Timmy added a comment -

          Hi, any updates with this issue? ​Adding Warnings NG's SourceCodeRetention setting was really helpful to me.

          Timmy added a comment - Hi, any updates with this issue? ​Adding Warnings NG's SourceCodeRetention setting was really helpful to me.

          Ulli Hafner added a comment -

          This issue is marked as "help-wanted", so pull requests are welcome. An implementation of the same feature exists in the coverage plugin and can be used as a boiler plate.

          Ulli Hafner added a comment - This issue is marked as "help-wanted", so pull requests are welcome. An implementation of the same feature exists in the coverage plugin and can be used as a boiler plate.

          This still doesn't work in warnings-ng 11.3.0. The recordIssues step accepts the sourceCodeRetention: 'NEVER' argument but retains the source code anyway; the console log shows "Copying affected files to Jenkins' build folder".

          AFAICT, the bug is that RecordIssuesStep.Execution.run() does not call IssuesRecorder.setSourceCodeRetention(step.getSourceCodeRetention()).

          drulli, should I file a new issue or open this one?

          Kalle Niemitalo added a comment - This still doesn't work in warnings-ng 11.3.0. The recordIssues step accepts the sourceCodeRetention: 'NEVER' argument but retains the source code anyway; the console log shows "Copying affected files to Jenkins' build folder" . AFAICT, the bug is that RecordIssuesStep.Execution.run() does not call IssuesRecorder.setSourceCodeRetention(step.getSourceCodeRetention()) . drulli , should I file a new issue or open this one?

          Ulli Hafner added a comment -

          Please file a new bug report.

          Ulli Hafner added a comment - Please file a new bug report.

          Kalle Niemitalo added a comment - - edited

          OK, filed as JENKINS-73164.

          Kalle Niemitalo added a comment - - edited OK, filed as JENKINS-73164 .

            drulli Ulli Hafner
            pmr Philipp Moeller
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: