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

Compute new warnings with a reference to a different job

XMLWordPrintable

      We use two different jobs in Jenkins to check our codebase.

      Our first job is run when a developer finished a feature and submits it for code review.
      The second job is run after every commit to our master branch, it runs the tests, checks the codestyle etc.

      Currently, the plugin allows us to compute new warnings since the last build. This is not always accurate, imagine:

      • Developer 1 sends his feature off for code review. It removes a lot of codestyle issues, yay!
      • The plugin checks the changes made by developer 1. It nicely reports the removed issues.
      • Developer 2 sends his feature to code review. It touches a healthier part of our codebase, but he's able to fix some issues, yay!
      • The plugin now checks the code developer 2 created. It notices several issues have returned, that developer 1 had just fixed. So the plugin now reports that developer 2 added lots of issues. In a part of the codebase, the developer didn't even touch.

      It would be better if the plugin would not compare the code made by dev 2 to the code of dev 1. It would be better if it could compare the code against the other job. The one that always has the code of the current master branch. Then we can check if the new code would add issues to the current codebase.

      I'm not really aware of what the possibilities are for such a feature. Maybe with some pointers in the right direction, I could have a go at it myself. But I've got no experience with building Jenkins plugins, so some help would really be appreciated.

          [JENKINS-28809] Compute new warnings with a reference to a different job

          Dennis Claassen created issue -
          Dennis Claassen made changes -
          Description Original: We use two different jobs in Jenkins to check our codebase.

          The first job is run after every commit to our master branch, it runs the tests, checks the codestyle etc.
          Our second job is run when a developer finished a feature and submits it for code review.

          Currently, the plugin allows us to compute new warnings since the last build. This is not always accurate, imagine:
          - Developer 1 sends his feature off for code review. It removes a lot of codestyle issues, yay!
          - The plugin checks developer 1 his changes. It nicely reports the removed issues.
          - Developer 2 sends his feature to code review. It touches a healthier part of our codebase, but he's able to fix some issues, yay!
          - The plugin now checks the code developer 2 created. It notices several issues have returned, that developer 1 had just fixed. So the plugin now reports that developer 2 added lots of issues. In a part of the codebase, the developer didn't even touch.

          It would be better if the plugin would not compare dev 2 his code to the code of dev 1. It would be better if it could compare the code against the other job. The one that always has the code of the current master branch. Then we can check if the new code would add issues to the current codebase.

          I'm not really aware of what the possibilities are for such a feature. Maybe with some pointers in the right direction, I could have a go at it myself. But I've got no experience with building Jenkins plugins, so some help would really be appreciated.           		New: We use two different jobs in Jenkins to check our codebase.

          Our first job is run when a developer finished a feature and submits it for code review.
          The second job is run after every commit to our master branch, it runs the tests, checks the codestyle etc.

          Currently, the plugin allows us to compute new warnings since the last build. This is not always accurate, imagine:
          - Developer 1 sends his feature off for code review. It removes a lot of codestyle issues, yay!
          - The plugin checks the changes made by developer 1. It nicely reports the removed issues.
          - Developer 2 sends his feature to code review. It touches a healthier part of our codebase, but he's able to fix some issues, yay!
          - The plugin now checks the code developer 2 created. It notices several issues have returned, that developer 1 had just fixed. So the plugin now reports that developer 2 added lots of issues. In a part of the codebase, the developer didn't even touch.

          It would be better if the plugin would not compare the code made by dev 2 to the code of dev 1. It would be better if it could compare the code against the other job. The one that always has the code of the current master branch. Then we can check if the new code would add issues to the current codebase.

          I'm not really aware of what the possibilities are for such a feature. Maybe with some pointers in the right direction, I could have a go at it myself. But I've got no experience with building Jenkins plugins, so some help would really be appreciated.

          Ulli Hafner added a comment -

          The reference build is quite easy to change, basically it is just a pointer to another build. What is not clear for me: is there a simple algorithm to determine the suggested reference build? If yes: what properties need to be added in the UI?
          And is your reference build something that is useful in a general way or just in your use case (is this related to JENKINS-13056?).

          Ulli Hafner added a comment - The reference build is quite easy to change, basically it is just a pointer to another build. What is not clear for me: is there a simple algorithm to determine the suggested reference build? If yes: what properties need to be added in the UI? And is your reference build something that is useful in a general way or just in your use case (is this related to JENKINS-13056 ?).

          Dennis Claassen added a comment -

          The feature described in JENKINS-13056 would be an even better fix for our current issue! My original idea made the assumption that the other job would always be the parent commit of the job under review, which does not have to be the case per se.

          Dennis Claassen added a comment - The feature described in JENKINS-13056 would be an even better fix for our current issue! My original idea made the assumption that the other job would always be the parent commit of the job under review, which does not have to be the case per se.
          Ulli Hafner made changes -
          Link New: This issue duplicates JENKINS-13056 [ JENKINS-13056 ]
          Ulli Hafner made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 163669 ] New: JNJira + In-Review [ 197273 ]
          Andrew Bayer made changes -
          Labels Original: configuration user-experience workflow New: configuration pipeline user-experience workflow
          Andrew Bayer made changes -
          Labels Original: configuration pipeline user-experience workflow New: configuration pipeline user-experience

          mirza zeyrek added a comment -

          claassen and drulli

          This feature would be awesome for us. For checking PR branch and MASTER branch there are always issues as mentioned in the task description. 

          Is there any progress on the task or how can I do it manually ? Changing reference job for checkstyle plug-in ?

          mirza zeyrek added a comment - claassen and drulli This feature would be awesome for us. For checking PR branch and MASTER branch there are always issues as mentioned in the task description.  Is there any progress on the task or how can I do it manually ? Changing reference job for checkstyle plug-in ?

            drulli Ulli Hafner
            claassen Dennis Claassen
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: