-
Bug
-
Resolution: Fixed
-
Minor
-
None
After updating the warnings plugin from 8.10.1 to 9.0.1 the number of warnings is inconsistent. I'm compiling several applications, sharing some sources in one jenkins project. If there is a warning in a shared code, it is logged once per application. As I know, before the update this log entries resulted in a single warning in the model. After the update there is one warning with one sub-report per logentry.
This are the warnings of our last builds:
| Build | Total | New | Fixed |
|---|---|---|---|
| #2976 | 5.702 | 4.234 | |
| #2975 | 5.698 | One | |
| #2974 | 5.698 | 4.231 | |
| #2973 | 5.687 | One | |
| #2972 | 5.687 | 4.220 | |
| #2971 | 5.687 | One | |
| #2970 | 5.687 | 4.220 | |
| #2969 | 5.687 | One | |
| #2968 | 5.687 | 4.222 | |
| #2967 | 5.643 | One | |
| #2966 | 5.643 | 4.179 | One |
| #2965 | 5.643 | One | |
| #2964 | 5.643 | 4.179 | |
| #2963 | 5.643 | One | |
| #2962 | 5.643 | 4.179 | |
| #2961 | 5.643 | One |
It seems there are two groups that alternate. Group A where the new warnings are One and group B where the new warnings are greater 4.000. Ich checked the behavior in another project. Both numers are different there, but the effect is the same.
This are the effects of the different areas in both groups:
Warnings Trend shows sub-reports for A and B.
Overview
| A | B |
|---|---|
| shows warnings | shows sub-reports |
 |
 |
Details Table Summary
| A | B |
|---|---|
| shows warnings | shows sub-reports |
 |
 |
Details Table content
| A | B |
|---|---|
| shows warnings | shows warnings |
 |
 |
Details on warnings level
| A | B |
|---|---|
| shows warnings | shows sub-reports |
 |
 |
- relates to
-
-
- Resolved
-
[JENKINS-65382] Inconsistent number of new warnings
| Summary | Original: Inconsistent number of warnings | New: Inconsistent number of new warnings |
I'm using a pipeline project with following command
recordIssues blameDisabled: true, aggregatingResults: true, filters: [includeModule('AK')], tools: [groovyScript(parserId: 'delphixe', pattern: 'target/log/*.log')]
In my opinion it would make more sense to solve the differnt behavior every second build at first.
Ok, then it makes sense to pick a build X with >4000 new warnings and select a warning that you will easily find in the previous build (where it was not marked as new). For these builds check the files
- [Jenkins]/jobs/[job-name]/builds/X/delphixe-new.xml
- [Jenkins]/jobs/[job-name]/builds/X-1/delphixe-outstanding.xml
and select the chosen warning and compare the properties: what is the difference?
I can't find the xmls.
The ui of the build can be found at:
http://svn:8880/job/AK4/job/ak4.trunk.svn/2976/ (we use the cloudbees-folder plugin)
When I try
http://svn:8880/jobs/AK4/ak4.trunk.svn/builds/2976/delphixe-new.xml
http://svn:8880/jobs/AK4/jobs/ak4.trunk.svn/builds/2976/delphixe-new.xml
http://svn:8880/jobs/AK4/ak4.trunk.svn/builds/2976/delphixe-outstanding.xml
http://svn:8880/jobs/AK4/jobs/ak4.trunk.svn/builds/22976/delphixe-outstanding.xml
I got an Jetty 404.
When I try
http://svn:8880/job/AK4/job/ak4.trunk.svn/2976/delphixe-new.xml
http://svn:8880/job/AK4/job/ak4.trunk.svn/2976/delphixe-outstanding.xml
I got the default ui without an xml.
Sorry: [Jenkins] should be replaced with JENKINS_HOME, you need to look on the disk...
| Attachment | New: delphixe-new-issues.xml [ 54617 ] | |
| Attachment | New: delphixe-outstanding-issues.xml [ 54618 ] |
I added the 2976\delphixe-new-issues.xml and 2975\delphixe-outstanding-issues.xml and replaced non relevant parts with ...
issue from 2975\delphixe-outstanding-issues.xml containing the properties that do not match the issues of 2976\delphixe-new-issues.xml
<issue> <severity reference="../../issue[48]/severity"/> <id>ba10985a-3ad0-4035-b755-71c7ee690ff1</id> <reference>2974</reference> <packageName reference="../../issue[631]/packageName"/> </issue>
issues from 2976\delphixe-new-issues.xml containing properties that do not match the issue of 2975\delphixe-outstanding-issues.xml
<issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>503a141a-c7da-4d81-9b86-8f5d2cfff0f9</id> <reference>2976</reference> <packageName reference="../../issue[42]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>7bd2b5d7-bd38-4083-9b24-544c20d192d1</id> <reference>2976</reference> <packageName reference="../../issue[43]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>1decd83f-366e-48d6-ba9f-9ce702d6bcaa</id> <reference>2976</reference> <packageName reference="../../issue[43]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>4d30075a-a5a1-49d8-b3ca-58fcc1220358</id> <reference>2976</reference> <packageName reference="../../issue[86]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>4c164020-f457-4fcf-9d40-b2ed91138ebe</id> <reference>2976</reference> <packageName reference="../../issue[73]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>d7bf5285-191d-4ade-a4d3-ecf1ce5bcae3</id> <reference>2976</reference> <packageName reference="../../issue[92]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>d0995d7c-2e4f-4364-a839-a7d0103ce50b</id> <reference>2976</reference> <packageName reference="../../issue[95]/packageName"/> </issue> <issue> <severity reference="../../../../analysisReport[2]/elements/issue[48]/severity"/> <id>bd399c13-612e-401f-85c8-2b8e7613a0bb</id> <reference>2976</reference> <packageName reference="../../issue[22]/packageName"/> </issue>
Hmm, strange. The different properties look fine. Severity and package is a reference just to save memory. Reference is the reference build which is not used in equals, id as well. Do you still have a result file of one of the builds before the upgrade? Maybe some properties are different.
What makes me wonder: all issues have a fall back fingerprint: <fingerprint>FALLBACK-2e4a982f</fingerprint>. Did the warnings plugin report errors that it cannot read your source files now?
Seems that we have two different issues here. Wrong computation of new warnings every second build and duplicate removal. I'm not sure what makes sense to discuss first.
What would help is if you could describe how you collect the warnings? Freestyle, pipeline, which command?