-
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
-
-
- Resolved
-
[JENKINS-28809] Compute new warnings with a reference to a different job
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. 
mirza zeyrek
added a comment - 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 ? mirza zeyrek
added a comment - And I'm quite confused. This marked as resolved but where is the solution exactly ? Am I missing something ?
mirza zeyrek
added a comment - And I'm quite confused. This marked as resolved but where is the solution exactly ? Am I missing something ? The resolution is "duplicate". Nobody worked on this yet.
Please watch the referenced issue.
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?).