The TAP test requires the perl-Test-Harness package, let's add it to the
build dependencies. It fails silently, but there is a message just when
the selftests are executed:

    + selftests/run
    Can't locate TAP/Parser.pm in @inc (you may need to install the
    TAP::Parser module) (@inc contains: /usr/local/lib64/perl5
    /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
    -e line 1.
    BEGIN failed--compilation aborted at -e line 1.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  Makefile: use setup.py for getting the current versions
  Result: have a fallback result instance
  HTML Result: use existing result instead of custom result dict
  HTML Result: give the right name to ReportModel input
  HTML result: use pkg_resources to locate required resources

Under some circumstances, getting the version indirectly through
`avocado/core/version.py` can return `unknown.unknown`.  Let's use the
authoritative source for version numbers: `setup.py` itself.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The way we're moving the result classes out of the ResultProxy
means that it's possible that no Result instances are present
in the proxy.  Since the results that are re-implemented using
the new interface depend on one result instance, let's
make sure there's at least one instance.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There are just too many intermediaries to the result generation.
Let's skip the custom result dict and just use the Result instance
that now contains all the test information.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

There's no JSON involved in the HTML result generation code.  Let's be
clear about what's being passed around.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `pkg_resources` API allows to set resources that are required for
specific packages.  One of the benefits of using this approach is the
increase of distribution options for Avocado, that is, it makes it
possible to use Avocado from a zip-based Python egg file (we are
currently set zip_safe=False), a Python wheel etc.

When it becomes possible to use Avocado from these distribution
formats (and when all Avocado dependencies are properly declared) a
Python project may be able to declare that it requires Avocado and
have everything fulfilled and installed from these portable formats
very easily.

At this time, this changes the use of the HTML resources files from
file mapping based on the location of the current module
(`sys.modules(__name__).__file__`) to the `pkg_resources` API.  It has
been tested with a zipped Python egg and works properly.  For other
types of installations, there is also no behavior change.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado.core.remote: Adjust to pretty json output

* https://github.com/avocado-framework/avocado:
  Introduce avocado job diff plugin
  avocado.core.replay record command line

This plugin will allow users to easily visualize the diff between 2
jobs, identified by their job ids.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Let's record the command line used to run Avocado. This will
be useful to retrieve the command line in job diffs.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

The commit e13734f5 broke the remote
execution as it depends on single-line json results output. This patch
adds a way to parse the output from pretty or single-line json output
(tested on avocado LTS and the current master)
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  added a function that return online cpu number {list}
  style-fixes :pep8

Signed-off-by: NPraveen K Pandey <praveen@linux.vnet.ibm.com>

Signed-off-by: NPraveen K Pandey <praveen@linux.vnet.ibm.com>

avocado.core.output: Wrap the lines in paginator

Currently we keep the long lines and let people to scroll left+right to
see the content. This patch changes the paginator to wrap the lines (by
default, it can be tweaked by environment variables).

For my workflows this works better as you see the full output on one
screen and you can easily copy&paste it without the need to scroll left
and right.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

JSON Result: output the result in pretty format

In the same fashion the default XUnit output has been made pretty,
let's not allow JSON to envy it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado.plugins.xml: Use pretty xml to make output human readable

The overhead of prettyxml is quite minimal, while the readability is
huge. Let's enable prettyxml by default to be able to read the results
manually.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  Result: remove command_line_arg_name attribute
  Result: port JSON result plugin
  Result: port xUnit result
  Result: introduce plugin interface and corresponding dispatcher
  Result: keep track of the state of all tests
  Result: be more specific about the the total time
  Result: drop "Test" from TestResult related classes names

* https://github.com/avocado-framework/avocado:
  setup.py: set minimum Python version requirements
  setup.py: automate package list
  Avocado version: rely on pkg_resources instead of hard coded number

The job-scripts are system-wide and always enabled when installed. Let's
skip the `coredump` one in case it's not executed as root to avoid big
fat warnings in every execution. Instead this patch adds a `stderr`
message informing user that coredump support was disabled because it's
not executed as root.

There is no need to modify the other coredump-related scripts as they
depend on files generated by this first script.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

docs: fix the version (release) number used by sphinx

The path variables need to be quotated.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Sphinx actually use the contents of the `release` variable as the
user visible version number, so release here is very different from,
say, a RPM release number.

Let's set the release number to the very same version number.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

So far there is no mention of the official minimum Python version
requirement.  This looks like the ideal place to set it, because it's
saved in the package metadata (sets standard "Requires-Python" info).

Support for this argument ("distribution" in setuptools lingo)
appeared in version 24.1, so a harmless warning is shown on earlier
versions.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Although the current implementation of the version module may look
simple, it imposes the loading of a huge number of modules for a
simple version lookup.  The reason is that a number of avocado
modules, including `avocado` (`avocado/__init__.py`) gets evaluated.
This module imports from many core parts of avocado, including
`core/job.py`, `core/test.py` which cascade to loading (and requiring)
a lot of packages for a simple version lookup.

This has restrained the use of `setup.py` in an environment without
all those requirements.  While `setup.py` may not be able to deliver
a functional Avocado without those requirements, it should not crash
as it does now.

For compatibility reasons, we'll keep the public API `avocado.VERSION`
and the core API `avocado.core.version.VERSION` will be kept just as
is.

Reference: https://trello.com/c/WmINCCMsSigned-off-by: NCleber Rosa <crosa@redhat.com>

* https://github.com/avocado-framework/avocado:
  Wrappers: add support for rr

This example wrapper script runs binaries inside rr (record), which
saves the execution environment, allowing to deterministically debug
possible failures later.

The usage instructions to run tests with this wrapper are no different
than other wrappers.  The effect of the wrapper, though, deserves notice:
it creates an "rr" directory inside the test results, which rr uses
to save its data files.

Replays should be executed like this:

 $ rr replay $JOB-RESULTS/test-results/$TEST/data/rr/$BINARY_NUMBER

Where $BINARY_NUMBER is the "Nth" execution of "binary" by your
test.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

With the change introduced in d205805b that changed how options request
the use of the standard output, this attribute is no longer necessary.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This moves all JSON result code to the plugin file.  With that, the
core avocado has no knowledge about this plugin, as it should be.
Still, the `results.json` is going to be generated by default, unless
the command line option `--json-job-result` is set to `off`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This moves all xUnit code to the plugin file.  With that, the core
avocado has no knowledge about this plugin, as it should be.  Still,
the `results.xml` is going to be generated by default, unless the
command line option `--xunit-job-result` is set to `off`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It's a known fact that the concept of results (as in job results) has
been abused.  Runners implemented as results prove that.  This minimal
interface is intended for Result implementations that render the
complete result at once.  This is the case for most *real* result
writer needs, such as XUnit, JSON (ported on the upcoming commits) and
even the HTML report writer (port coming soon)

Once all results are ported, the ResultProxy, our more custom and old
fashioned form of a dispatcher, can be removed.  Then, the job
attribute `result`, which is currently a ResultProxy instance with
multiple Result* classes holding a lot of duplicate information, will
be turned into a single instance.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

In a planned change of goal for the result class to actually hold one
copy of the overall job results, and then introduce specific result
formatters that will use that as the data to write varied result
formats, let's add all test information to the result class.
Signed-off-by: NCleber Rosa <crosa@redhat.com>