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

Add permissions for source code viewer

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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. 

       

        Attachments

          Issue Links

            Activity

            Hide
            drulli 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.

            Show
            drulli 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.
            Hide
            haraldv 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?

            Show
            haraldv 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?
            Hide
            drulli 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.

            Show
            drulli 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.
            Hide
            romanz 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).

            Show
            romanz 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).
            Hide
            kon Kalle Niemitalo added a comment -

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

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

            Kalle Niemitalo 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.

            Show
            romanz Roman Zwi added a comment - Kalle Niemitalo 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.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              hangdong Hang Dong
              Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated: