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

Warnings plugin has renumbered internally - breaks builds!

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Component/s: warnings-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.476, warnings 4.13
    • Similar Issues:

      Description

      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?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                drulli Ulli Hafner
                Reporter:
                torbent torbent
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: