We would like to request for an option to disable warning plugin's parsing and displaying of project source code (source code view feature); ideally having the ability to set it at instance/master level as well as project's parser level. 

      For very large project where we are more interest in tracking metric, we found this parse/displaying to be expensive on storage; in addition we notice view content permission is tied to job read permission (more open in our instance), instead workspace permission (limited to admin) - in our env with mix-ed repo with diff permission level but builds together, this can potentially exposes source code when we want intended to share build result/console output. 

       

          [JENKINS-61038] Add permissions for source code viewer

          Ulli Hafner added a comment -

          That makes sense to look into at a higher level. As already discussed with the coverage-api team it would make sense to extract the source code rendering into a new plugin that has all those features in a single place.

          Ulli Hafner added a comment - That makes sense to look into at a higher level. As already discussed with the coverage-api team it would make sense to extract the source code rendering into a new plugin that has all those features in a single place.

          We use the cobertura coverage plugin that uses workspace permision to decide if source code can be viewed by a user or not. But if the same source contains warnings or static code analysis messages it will be visible regardles of the permissions.

          Can I help to get a solution for this?

          Harald Villinger added a comment - We use the cobertura coverage plugin that uses workspace permision to decide if source code can be viewed by a user or not. But if the same source contains warnings or static code analysis messages it will be visible regardles of the permissions. Can I help to get a solution for this?

          Ulli Hafner added a comment -

          If you are interested in providing a PR you are welcome! Using the workspace permission isn't exactly what we need, but it might be better than nothing.

          Ulli Hafner added a comment - If you are interested in providing a PR you are welcome! Using the workspace permission isn't exactly what we need, but it might be better than nothing.

          Roman Zwi added a comment -

          Quick workaround that worked for me:
          Configure a custom groovy parser that doesn't set the filename.
          So Warnings NG doesn't know the file name and can't do anything about it (this also avoids NoSuchFileException and storage issues).

          Roman Zwi added a comment - Quick workaround that worked for me: Configure a custom groovy parser that doesn't set the filename. So Warnings NG doesn't know the file name and can't do anything about it (this also avoids NoSuchFileException and storage issues).

          But if Warnings NG does not know the file names, then it cannot report them to Checks API either.

          Kalle Niemitalo added a comment - But if Warnings NG does not know the file names, then it cannot report them to Checks API either.

          Roman Zwi added a comment -

          kon you are right, of course - we included the file name in the message text instead.
          We actually need the Jenkins builds only as an additional validation step.

          Roman Zwi added a comment - kon you are right, of course - we included the file name in the message text instead. We actually need the Jenkins builds only as an additional validation step.

            Unassigned Unassigned
            hangdong Hang Dong
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: