Package: mlx.warnings
Command Line Warnings PluginCommand-line alternative forhttps://github.com/jenkinsci/warnings-plugin.
Useable with plugin-less CI systems. It can be used with GitLab-CI to enable
warning threshold setting for failing the job and for parsing warnings from
various tools and report them as errors.InstallationEvery release is uploaded to pip so it can be installed simply by using pip.# Python3pip3installmlx.warningsYou can find more details in theInstallation guide.UsageWarnings plugin parses log messages as well as direct command stream. In case you
want to create log file, you will need to redirect your stderr to some text file.
You can do that with shell pipes or with
command line arguments to command (if it supports outputting errors to file
instead of stderr). Be aware that some commands print warnings on stdout.Also warnings plugin log files need to be the last argument as otherwise the
arguments after that are discarded, because they are considered as command
arguments (with or without command flag).Pipe ExampleBelow is one of the ways to redirect your stderr to stdout and save it inside a
file.yourcommand2>&1|teedoc_log.txtCommand ExampleBelow is the command example for the plugin (keep in mind that parse commands are
required).mlx-warnings--command<yourcommand>Running CommandThere are few ways to run warnings plugin. If you are playing with Python on
your computer you want to usevirtualenv. This will separate your packages
per project and there is less chance of some dependency hell. You can
initialize virtual environment in current directory byvirtualenv ..Melexis Warnings plugin can be called directly from shell/console using:mlx-warnings-hIt has also possibility to be called as module frompython3. In
that case command will look like:python3-mmlx.warnings-hHelp prints all currently supported commands and their usages.The command returns (shell $? variable):value 0 when the number of counted warnings is within the supplied minimum and maximum limits: ok,number of counted warnings (positive) when the counter number is not within those limit (1 in case of 0 counted warnings).Simple Command Line OptionsPlugin has two forms of passing the arguments to checkers. The command line
option which enables checkers and sets minimum and maximum to each checker
individually, or the configuration file option which provides more flexibility
and also traceability as it resides inside repository and provides option to
adjust minimum and maximum per individual checker.Parse for Sphinx WarningsAfter you saved your Sphinx warnings to the file, you can parse it with
command:# command line log filemlx-warningsdoc_log.txt--sphinx# command line command executionmlx-warnings--sphinx--command<commandforsphinx># explicitly as python module for log filepython3-mmlx.warnings--sphinxdoc_log.txtpython-mmlx.warnings--sphinxdoc_log.txt# explicitly as python modulepython3-mmlx.warnings--sphinx--command<commandforsphinx>python-mmlx.warnings--sphinx--command<commandforsphinx>Parse for Doxygen WarningsAfter you saved your Doxygen warnings to the file, you can parse it with
command:# command line log filemlx-warningsdoc_log.txt--doxygen# command line command executionmlx-warnings--doxygen--command<commandfordoxygen># explicitly as python module for log filepython3-mmlx.warnings--doxygendoc_log.txtpython-mmlx.warnings--doxygendoc_log.txt# explicitly as python modulepython3-mmlx.warnings--doxygen--command<commandfordoxygen>python-mmlx.warnings--doxygen--command<commandfordoxygen>Parse for Coverity DefectsCoverity is a static analysis tool which has option to run desktop analysis
on your local changes and report the results back directly in the console.
You only need to list affected files and below example lists changed files
between your branch and master, which it then forwards tocov-run-desktop:cov-run-desktop--text-output-style=oneline`gitdiff--name-only--ignore-submodulesmaster`You can pipe the results to logfile, which you pass to warnings-plugin, or you use
the--commandargument and execute thecov-run-desktopthrough# command line log filemlx-warningscov-run-desktop-output.txt--coverity# command line command executionmlx-warnings--coverity--command<commandforcoverity># explicitly as python module for log filepython3-mmlx.warnings--coveritycov-run-desktop-output.txtpython-mmlx.warnings--coveritycov-run-desktop-output.txt# explicitly as python modulepython3-mmlx.warnings--coverity--command<commandforcoverity>python-mmlx.warnings--coverity--command<commandforcoverity>Parse for JUnit FailuresAfter you saved your JUnit XML output to the file, you can parse it with
command:# command line log filemlx-warningsjunit_output.xml--junit# command line command executionmlx-warnings--junit--command<commandforjunit># explicitly as python module for log filepython3-mmlx.warnings--junitjunit_output.xmlpython-mmlx.warnings--junitjunit_output.xml# explicitly as python modulepython3-mmlx.warnings--junit--command<commandforjunit>python-mmlx.warnings--junit--command<commandforjunit>Parse for XMLRunner ErrorsWhen you runXMLRunner,
the errors are reported on the output, but they are not marked as failures in
the test reports xml files. Since command exits as 1, we could not detect tests
that just did not run (not failed). warnings-plugin now parses for the output
with command:# command line log filemlx-warningsxmlrunner_log.txt--xmlrunner# command line command executionmlx-warnings--xmlrunner--command<commandforxmlrunner># explicitly as python module for log filepython3-mmlx.warnings--xmlrunnerxmlrunner_log.txtpython-mmlx.warnings--xmlrunnerxmlrunner_log.txt# explicitly as python modulepython3-mmlx.warnings--xmlrunner--command<commandforxmlrunner>python-mmlx.warnings--xmlrunner--command<commandforxmlrunner>Parse for Robot Framework Test FailuresWhen runningRobot Frameworktests with--xunitreport.xmlas an input
argument, an xUnit compatible result file is generated. The warnings-plugin can
parse this file and check the amount of failures. By default, the test results
of all test suites in the file are taken into account. If you only care about
one specific test suite, you can use--name<<suite name>>. If this suite
name doesn’t exist in the input file, an error is raised. The warning
limits can be configured for multiple test suites individually by means of aconfiguration file to pass options. If the setting"check_suite_names"is false, no error is raised when a suite name doesn’t exist in the
input file. When this setting is missing, the default valuetrueis used.# command line xunit filemlx-warnings--robotreport.xml# ignore all but the specified suitemlx-warnings--robot--name"Suite Name"report.xml# explicitly as python modulepython3-mmlx.warnings--robot--name"Suite Name"report.xmlConfiguration File to Pass OptionsBeside command line, you can pass options through the configuration file.
Configuration file is in JSON orYAMLformat with a simple structure.
The values for ‘min’ and ‘max’ can be set with environment variables via astring.Template, e.g."${MAX_SPHINX_WARNINGS}".{"sphinx":{"enabled":true,"cq_default_path":"doc/source/conf.py","cq_description_template":"$PRODUCT | $description","min":0,"max":"${MAX_SPHINX_WARNINGS}"},"doxygen":{"enabled":true,"cq_default_path":"doc/doxygen/Doxyfile","min":"$MIN_DOXY_WARNINGS","max":"$MAX_DOXY_WARNINGS"},"junit":{"enabled":false,"min":0,"max":0},"xmlrunner":{"enabled":false,"min":0,"max":0},"coverity":{"enabled":false,"min":0,"max":0},"robot":{"enabled":false,"check_suite_names":true,"suites":[{"name":"My First Suite","min":8,"max":10},{"name":"My Second Suite","min":0,"max":0}]}}First key ischeckername, then it contains a boolean value for keyenabled,
value for minimum number of warnings with keyminand value for maximum
number of warnings with keymax. This structure allows simple expansion.To run the plugin with configuration file you simply pass--configflag with
path to configuration file# command line log filemlx-warnings--configpath/to/config.jsonjunit_output.xml# command line command executionmlx-warnings--configpath/to/config.json--command<commandforjunit>Other OptionsSince the plugin is under active development there are new Features added fast.
Important options currently include setting a minimum and a maximum number of warnings
that are still acceptable to return 0 (success). Requiring an exact amount of warnings
using a single option is also possible. Look at scripts help for more details about the options.Exclude Matches With RegexesIn case you want a checker to exclude certain matches, you can configure
one or more regular expressions in the configuration file on a per-checker basis.
If a pattern of a regex to exclude is found in a match of the checker’s regex, the checker
won’t count that match. Add the regex(es) as a list of string values for theexcludekey.
An example configuration for the sphinx checker is given below:{"sphinx":{"enabled":true,"min":0,"max":0,"exclude":["RemovedInSphinx\\d+Warning","WARNING: toctree"]}}Exclude Sphinx Deprecation WarningsThere is a special flag--exclude-sphinx-deprecationthat lets the sphinx checker exclude
Sphinx deprecation warnings. These warnings match the following regular expression:RemovedInSphinx\\d+Warning. Using this flag results in the same behavior as adding this
regex to the configuration file as value for theexcludekey for the sphinx checker.Store All Counted WarningsUse-o, –output <file_path>to let the plugin write all counted warnings/failures as strings to a text file.
This can help you separate the warnings/failures that matter from those that are excluded or from irrelevant text that
may exist in the input file (or produced by the given command).Code Quality ReportUse-C,--code-qualityto let the plugin generatea Code Quality reportfor GitLab CI. All counted
Sphinx, Doxygen and XMLRunner will be included. Other checker types are not supported by this feature. The report is
a JSON file that implementsa subset of the Code Climate spec. Define this fileas a codequality report artifactof the CI job.If a warning doesn’t contain a path,"cq_default_path"from theconfiguration file to pass optionswill be used.
If not configured,.gitlab-ci.ymlwill be used as a fallback path.You can customize the description with"cq_description_template", seeconfiguration file to pass options.
Its value should be a template for Python’sstring.Template. The template should contain$descriptionand has
access to all environment variables, e.g.$HOME.Issues and New FeaturesIn case you have any problems with usage of the plugin, please open an issue
on GitHub. Provide as many valid information as possible, as this will help us
to resolve Issues faster. We would also like to hear your suggestions about new
features which would help your Continuous Integration run better.ContributeThere is a Contribution guide available if you would like to get involved in
development of the plugin. We encourage anyone to contribute to our repository.