Uploaded image for project: 'Infrastructure'
  1. Infrastructure
  2. INFRA-2294

configure the default plugin pipeline to use static analysis plugins for visualisation

    Details

    • Similar Issues:

      Description

      Whilst looking at https://github.com/jenkinsci/plugin-pom/pull/236 I discovered we have no UI reporting of static analysis violations in ci.jenkins.io for core or plugin builds.

       

      We should install the warnings ng plugin and hook it up for spotbugs (and other issues such as java compilation warnings) for the core and plugin builds.

       

        Attachments

          Issue Links

            Activity

            Show
            danielbeck Daniel Beck added a comment - Is this obsolete after https://github.com/jenkinsci/plugin-pom/pull/236#issuecomment-541686479 ?
            Hide
            teilo James Nord added a comment -

            Ulli Hafner is using a custom Jenkinsfile for his plugin.  So I think we should just improve `buildPlugin()` to do this by default.

            Show
            teilo James Nord added a comment - Ulli Hafner is using a custom Jenkinsfile for his plugin.  So I think we should just improve `buildPlugin()` to do this by default.
            Hide
            drulli Ulli Hafner added a comment -

            This is on my todo list since a long time I'm also using the tools a little bit different in the pom (verify phase rather directly) so I'm not sure if I should change that as well.

            Show
            drulli Ulli Hafner added a comment - This is on my todo list since a long time I'm also using the tools a little bit different in the pom (verify phase rather directly) so I'm not sure if I should change that as well.
            Hide
            drulli Ulli Hafner added a comment - - edited

            What is a good approach to test such changes? Seems that referencing a modified buildPlugin.groovy in one of my Jenkinsfiles is not so easy? I can copy and paste everything into my Jenkinsfile as I am doing right now but this is not really elegant...

            Show
            drulli Ulli Hafner added a comment - - edited What is a good approach to test such changes? Seems that referencing a modified buildPlugin.groovy in one of my Jenkinsfiles is not so easy? I can copy and paste everything into my Jenkinsfile as I am doing right now but this is not really elegant...
            Hide
            olblak Olivier Vernin added a comment -

            As far as I know, there are no real alternatives to test on ci.j.io

            Test as much as you can on your local Jenkins instance, then modify the buildplugin() with a parameter to enable/disable based on a condition in order to validate your modification

            Or copy/paste in your Jenkinsfile project

             

            Show
            olblak Olivier Vernin added a comment - As far as I know, there are no real alternatives to test on ci.j.io Test as much as you can on your local Jenkins instance, then modify the buildplugin() with a parameter to enable/disable based on a condition in order to validate your modification Or copy/paste in your Jenkinsfile project  
            Hide
            drulli Ulli Hafner added a comment -

            I created a draft PR.

            I have two questions that we need to discuss before I can finish the work on the PR (tests etc.):

            • I removed the maven configuration on how to start the tools. I'm not sure if I am using Maven the wrong way but I think that this part should belong to the pom and not into the buildPlugin step. In my jobs I configure all analysis tools in the pom so that maven verify will invoke automatically the static analysis tools that I want (with my configuration files and options). The warnings plugin is smart enough to not break the build if there are no reports written.
            • I did not yet activate the quality gates. I'm not sure if someone already is using that feature? A total warnings of 0 is quite hard too achieve. And computation of new warnings does not make much sense until the automatic baseline selection is working (one of my student is working in his thesis on that problem). Can I obtain the job name somehow in this groovy script? Then I can at least set the reference build (that is use to compute the new warnings against) to the right job: referenceJobName: Plugins/[job-name]/master.
            Show
            drulli Ulli Hafner added a comment - I created a draft PR . I have two questions that we need to discuss before I can finish the work on the PR (tests etc.): I removed the maven configuration on how to start the tools. I'm not sure if I am using Maven the wrong way but I think that this part should belong to the pom and not into the buildPlugin step. In my jobs I configure all analysis tools in the pom so that maven verify will invoke automatically the static analysis tools that I want (with my configuration files and options). The warnings plugin is smart enough to not break the build if there are no reports written. I did not yet activate the quality gates. I'm not sure if someone already is using that feature? A total warnings of 0 is quite hard too achieve. And computation of new warnings does not make much sense until the automatic baseline selection is working (one of my student is working in his thesis on that problem). Can I obtain the job name somehow in this groovy script? Then I can at least set the reference build (that is use to compute the new warnings against) to the right job: referenceJobName: Plugins/ [job-name] /master .
            Hide
            timja Tim Jacomb added a comment -

            I believe you can rename buildPlugin to be buildPlugin2 and then test you branch / fork by loading the library with the `library` step

            Show
            timja Tim Jacomb added a comment - I believe you can rename buildPlugin to be buildPlugin2 and then test you branch / fork by loading the library with the `library` step
            Hide
            drulli Ulli Hafner added a comment -

            Tim Jacomb I tested it in the meantime by just copying everything into the Jenkinsfile and removing the method definition in the beginning.

            Show
            drulli Ulli Hafner added a comment - Tim Jacomb I tested it in the meantime by just copying everything into the Jenkinsfile and removing the method definition in the beginning.

              People

              • Assignee:
                drulli Ulli Hafner
                Reporter:
                teilo James Nord
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: