Tools like PMD or CheckStyle define such priorities globally for all users. Would it make sense to define a global mapping table in the parser (which one are you using?)? Or do you think this is something that different teams would handle differently?

I'm using both gcc and MSBuild parsers for different projects.

I think different teams would be using different settings here, as they may have different views on the severity of stylistic warnings.

I think there is no need to make this parser specific. There is already a setting "Categories to ignore", this feature would add "High/Medium/Low Categories" and/or replace that by a mapping table where users can override default classifications with "High/Medium/Low/Ignore".

It might also be useful to some people to have a similar mechanism for matches against file names or warning messages and/or combinations of these (e.g. demote certain warnings in third-party components without hiding them), but this would probably increase the complexity quite a bit.

I see.

I wonder if it would make sense to introduce a kind of priority mapping file (local in the workspace) that would map a given warning property to a priority. This would be more powerful and should be simpler to implement than a Ui.

Three disadvantages of a separate file:

• doesn't allow different project instances in Jenkins to have different settings (e.g. a "janitor" team would be interested in different things than the people working on new features
• doesn't allow applying different settings to old versions
• the file would have to contain mappings for multiple compilers (e.g. we build with gcc, clang and Visual Studio), so we'd need a mechanism to avoid conflicts.

At least for me, it would also be annoying to use, as we don't have CI infrastructure inside the project, so I'd have to maintain a separate branch that gets merged for every build.