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

Compute new warnings with a reference to a different job

      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 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 made changes -
          Resolution Original: Duplicate [ 3 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]
          Ulli Hafner made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Reopened [ 4 ] New: Resolved [ 5 ]

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

              Created:
              Updated:
              Resolved: