Add Warnings Next Generation Plugin

[rotu]

The Warnings plugin currently in use is deprecated. This adds the warnings-ng plugin to replace it.
See also #358 which removes the old plugin.

[dirk-thomas]

Adding @nuclearsandwich as a reviewer since he is in charge of our Jenkins infrastructure.

[nuclearsandwich]

@rotu are you testing this PR against an internal Jenkins deployment? I would like to set it up on my test CI deployment but knowing what state to expect would really help there.

[rotu]

I don’t know how to test this PR. I cobbled it together using Jenkins installed on my Mac.

[rotu]

@nuclearsandwich rebased.

[j-rivero]

@nuclearsandwich rebased.

Thanks Dan. I've looked into the changes, mostly looks good to me. I'm afraid of unconditionally enable all compiler parsers in all the jobs, not sure if the new plugin handle it in a smart way. Just in case, I've add some code to only enable compilers based on platforms or the use of clang. Feel free to comment or cherry-pick.

I'm planning to give this changes and the update of the plugin a run on a testing build farm.

[rotu]

@j-rivero I don't love that change - we should be basing it on (1) the identity of the actual compiler (2) just the output of that compiler, not the output of other things in the log like tests. Still I suppose it's better than no filtering.

[j-rivero]

@j-rivero I don't love that change - we should be basing it on (1) the identity of the actual compiler

Do we have a better way of detecting the actual compiler at the moment of generating the job configuration files? I agree that the approach is not rock-solid but given the limited number of options I think that is reasonable at this point to use compile_with_clang_default and assume osx = clang and windows = msbuild.

(2) just the output of that compiler, not the output of other things in the log like tests. Still I suppose it's better than no filtering.

How changes in this PR can limit the scope in which the warning parser operates?

[rotu]

How changes in this PR can limit the scope in which the warning parser operates?

out of scope for this PR. Just a consideration for the future

[j-rivero]

I agree that the approach is not rock-solid but given the limited number of options I think that is reasonable at this point to use compile_with_clang_default and assume osx = clang and windows = msbuild.

After given another look at this, there is a parameter at the moment of launching the build that allows the user to select Clang in Linux instead of Gcc. I've changed the code to run all the times gcc+clang on Linux, clang on Osx and msbuild on Win. Parsers have been typically fast even in long logs, I would not expect significant increases of time even with various parsers enabled.

@rotu would you mind pulling changes from master...j-rivero:warning_new_gen? (for some reason I can not push to your branch sorry). Let me know if you prefer that I open a different PR.

[rotu]

@j-rivero Rebased and merged your branch in.

[j-rivero]

merge ready in #404