-
New Feature
-
Resolution: Duplicate
-
Major
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.
- duplicates
-
JENKINS-13056 Obtain reference build from SCM/Trigger
-
- Resolved
-
[JENKINS-28809] Compute new warnings with a reference to a different job
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. |
Link |
New:
This issue duplicates |
Resolution | New: Duplicate [ 3 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Workflow | Original: JNJira [ 163669 ] | New: JNJira + In-Review [ 197273 ] |
Labels | Original: configuration user-experience workflow | New: configuration pipeline user-experience workflow |
Labels | Original: configuration pipeline user-experience workflow | New: configuration pipeline user-experience |
Resolution | Original: Duplicate [ 3 ] | |
Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Resolution | New: Duplicate [ 3 ] | |
Status | Original: Reopened [ 4 ] | New: Resolved [ 5 ] |