-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Jenkins 1.476, warnings 4.13
We have some jobs where we fail builds if there are new warnings. After upgrading to warnings-4.13, it appears that the "MSBuild" parser has changed its internal number from 25 to 27, causing all warnings to be counted as New, thus failing every single build since the upgrade.
I think the renumbering is to blame because I can see in my logs that a request for a file called "compiler-27-warnings.xml" fails. Such a file is indeed present in the new builds, whereas the old builds instead have a file called "compiler-25-warnings.xml". I also have files called "compiler-1-warnings.xml" (dynamic parser) and "compiler-warnings.xml" (all parsers combined).
So it looks to me that MSBuild has changed value (an enum, perhaps?). This breaks all our builds. We can probably save them by re-configuring to not check for new warnings, build once, and then re-enable the check, but I don't really want to do that every time new parsers are added to the plugin!
So may I suggest that it be written explicitly in the plugin code that existing parsers under no circumstances should change number?
Or that the filenames be based on something a little more "predictable" than an enum? Or perhaps the file with all warnings could be used instead?
- duplicates
-
JENKINS-14570 Warnings plugin tries to load wrong compiler-warnings.xml file
-
- Resolved
-
Also (but I don't know if it's the same root cause), for the dynamic parser it reports (e.g.) 48 new warnings, but when following the link to those new warnings, I get an empty list.
There are no messages in my Jenkins log for this.