Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-58167

Add option to not store affected files

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            drulli Ulli Hafner added a comment -

            Maybe we should provide the same options as the coverage API plugin.

            Show
            drulli Ulli Hafner added a comment - Maybe we should provide the same options as the coverage API plugin.
            Hide
            sladyn98 Sladyn Nunes added a comment -

            Ulli Hafner I would like to get started with this issue, any pointers on getting started with this ?

            Show
            sladyn98 Sladyn Nunes added a comment - Ulli Hafner I would like to get started with this issue, any pointers on getting started with this ?
            Hide
            drulli Ulli Hafner added a comment -

            One thing to start with is to have a look at the coverage-api plugin and see which options they provide for the user.

            Then we can discuss if we are heading for the simple solution (boolean flag) or a more sophisticating approach. One question for the latter one is: should this be solved in my plugin? Or should this be part of a source code renderer plugin that handles such a thing for all Jenkins plugins that show source code in some form. I discussed this in the coverage API Gitter channel a couple of weeks ago. I think providing a plugin would definitely be the best way but also the most complex one. I think this would be a GSoC project on its own...

            Show
            drulli Ulli Hafner added a comment - One thing to start with is to have a look at the coverage-api plugin and see which options they provide for the user. Then we can discuss if we are heading for the simple solution (boolean flag) or a more sophisticating approach. One question for the latter one is: should this be solved in my plugin? Or should this be part of a source code renderer plugin that handles such a thing for all Jenkins plugins that show source code in some form. I discussed this in the coverage API Gitter channel a couple of weeks ago. I think providing a plugin would definitely be the best way but also the most complex one. I think this would be a GSoC project on its own...
            Hide
            sladyn98 Sladyn Nunes added a comment -

            Yeah I seen the thread on gitter, well then I guess I should move on to picking another issue, since the scope for the implementation is pretty wide.

            Show
            sladyn98 Sladyn Nunes added a comment - Yeah I seen the thread on gitter, well then I guess I should move on to picking another issue, since the scope for the implementation is pretty wide.

              People

              • Assignee:
                Unassigned
                Reporter:
                pmr Philipp Moeller
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: