New option to require an exact amount of warnings

• Added: a new option to require an exact amount of warnings to be counted: see #88
• Fixed: no longer return 0 on certain failures: see #89

Optional detection of sphinx deprecation warnings

Sphinx deprecation warnings were counted before as a normal warning, but that proved to be counter-productive as projects usually do not want to care about plugin/infrastructure warnings. That is why default behavior now is changed so that deprecation warnings do not count, but you can turn the feature on in configuration file or with command line flag.

Improve Sphinx warnings detection

Sphinx warning without document name is now counted as normal warning.

Improve doxygen regex and drop support for python2

Improve doxygen regex so that it does not identify git notes and Sphinx deprecation warnings as doxygen warnings when you run the warnings via command line or over file containing all these warnings.

Drop support for python2, otherwise no other backwards compatibility changes. Some minor maintainability fixes and pylint fixes.

Adding Coverity checker

Adding the Coverity regex checker. Parses input from cov-run-desktop command.

Remove runtime dependency on setuptools_scm

• Major problem was malfunctioning setuptools_scm, which was a run time dependency because of easier version obtaining. This was removed by #70 as now it should burn the version at packaging.
• Versioning for docs was also fixed in #71
• Deprecated support for Python 3.3

Adding xmlrunner parser for Python unit test

XMLRunner reports errors on output, but they are not logged inside the reports. New checker is deployed to warnings plugin to parse the output and fail the build when there are errors in XMLRunner. So far it only checks for errors and does not parse reports for the failures.

0.2.0

add json configparser for allowing more flexible and traceable configuration

Bugfix: Empty logfile should fail the check

There was an issue described in #54 where empty logfile passed the empty input to checker and return was a success - which is faulty.

Bugfix: Ignore return value with command option

We were ignoring a return value of the program we executed with --command flag. This release fixes that and it also adds an optional argument where ignoring program return value is expected behavior (then warnings are parsed and decision is taken on that).

Be aware that ignoring command return value can have a side effect where command fails, does not produce any output, therefor there are no warnings, so plugin marks it as passed.