-
Bug
-
Resolution: Fixed
-
Major
-
None
In warnings v4.24, the clang/llvm parser was renamed from "Apple LLVM Compiler (Clang)" to "Clang (LLVM based)". That's fine, I'm cool with better naming.
Problem is, updating to warnings v4.24 silently broke my config in a very bad way. :-O
When `warnings` cannot find a match, it seems to silently default to the nearest alphabetic match, which in my case turns out to be of all things "Acu COBOL", and so suddenly and silently all my clang/llvm jobs were running with completely the wrong parser.
If hadn't noticed this by chance I'd have been happily running the wrong parser for who knows how long. I don't think I need to expand on how horribly bad it is to fail silently in this way.
Quick fix:
Yell and bail out if a parser name is not an EXACT match instead of defaulting to the nearest alphabetic match (alphabetic match seems worse the more one thinks about it).
Long-term fix:
Identify and store parsers by ID rather than the human-readable name so that amendments to the human-readable name don't touch the config.
Hope this is useful,
Richard.
[JENKINS-17762] Renaming the Clang parsers silently breaks Jenkins configs
Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/WarningsPublisher.java
src/test/java/hudson/plugins/warnings/parser/ParserRegistryIntegrationTest.java
http://jenkins-ci.org/commit/warnings-plugin/475666b83c000825c518b5dfc1f60e7202d4ba66
Log:
[FIXED JENKINS-17762] Replace old parser names with new names.
During de-serialization the old parser names should be replaced
with the new names otherwise the UI can't show the selected parser.
Ok, I finally fixed it. Actually, only the UI part was broken. All your jobs should still use the correct parser during processing...
Thanks for your prompt work, Ulli. Let me make sure that I understand you correctly:
1. Even though my config.xml had `<parserName>Apple LLVM Compiler (Clang)</parserName>`, the correct parser was still being used after I updated from warnings 4.23 to 4.24.
2. The display of "Acu COBOL" on editing my config after updating to warnings 4.24 was a UI-only glitch.
3. Suppose that, unaware of this issue and running warnings 4.24, I had edited only another aspect of my config (say, the log rotator) and saved the config? Would the parser name have stayed as "Apple LLVM Compiler (Clang)" or would it have been changed to "Acu COBOL"? Just trying to cover all bases.
Regards,
Richard.
Richard Buckle
added a comment - - edited Thanks for your prompt work, Ulli. Let me make sure that I understand you correctly:
1. Even though my config.xml had `<parserName>Apple LLVM Compiler (Clang)</parserName>`, the correct parser was still being used after I updated from warnings 4.23 to 4.24.
2. The display of "Acu COBOL" on editing my config after updating to warnings 4.24 was a UI-only glitch.
3. Suppose that, unaware of this issue and running warnings 4.24, I had edited only another aspect of my config (say, the log rotator) and saved the config? Would the parser name have stayed as "Apple LLVM Compiler (Clang)" or would it have been changed to "Acu COBOL"? Just trying to cover all bases.
Regards,
Richard. 1. Even though my config.xml had `<parserName>Apple LLVM Compiler (Clang)</parserName>`, the correct parser was still being used after I updated from warnings 4.23 to 4.24.
Yes, that is true.
2. The display of "Acu COBOL" on editing my config after updating to warnings 4.24 was a UI-only glitch.
Yes.
3. Suppose that, unaware of this issue and running warnings 4.24, I had edited only another aspect of my config (say, the log rotator) and saved the config? Would the parser name have stayed as "Apple LLVM Compiler (Clang)" or would it have been changed to "Acu COBOL"? Just trying to cover all bases.
No, then the parser will be changed to the Cobol Compiler. (If you did not manually change the value of the list box).
Richard Buckle
added a comment - Thanks again Ulli. I shall update my blog post to reflect this information.
Regards,
Richard.
Richard Buckle
added a comment - Thanks again Ulli. I shall update my blog post to reflect this information.
Regards,
Richard. Richard Buckle
added a comment - Hi Ulli, I have looked around in GitHub but I'm unclear in which release this fix is deployed. Please forgive my lack of experience with the release process. If you could please point me to the release that includes this fix, I'd be very grateful!
Richard Buckle
added a comment - Hi Ulli, I have looked around in GitHub but I'm unclear in which release this fix is deployed. Please forgive my lack of experience with the release process. If you could please point me to the release that includes this fix, I'd be very grateful! 
Kevin Fleming
added a comment - I just ran a build with 4.25 installed (I had forgotten to update before starting the build), and now the build shows Cobol warnings (of which there were none since the code is C++) and not Clang warnings. I have reconfigured the job to use the Clang parser, but the existing build still shows the wrong warnings output.
Kevin Fleming
added a comment - I just ran a build with 4.25 installed (I had forgotten to update before starting the build), and now the build shows Cobol warnings (of which there were none since the code is C++) and not Clang warnings. I have reconfigured the job to use the Clang parser, but the existing build still shows the wrong warnings output. 
Hi Ulli, you can find the configs at https://github.com/richardbuckle/AdvancedJenkins in the "jobs" subdirectory. The commit in question is https://github.com/richardbuckle/AdvancedJenkins/commit/67d706fbb15da8fad66b3749a656098195df58ee
If you've any questions do please ask.