Basic security guidelines advice to use `sudo` to run docker. We have
the support for this via `--docker-cmd` so let's use it in the
demonstration example to make it more visible. Additionally this should
make it easier for people to just follow the example without the need to
configure their docker to run as non-root without sudo.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The `` `` does not work in sphinx. Let's use ``" "`` instead and use the
same way for other items in this paragraph to avoid confusion.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The other's is used as other people tests, which is a valid usage.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Testplan related bugfixes [v2]

* https://github.com/avocado-framework/avocado:
  Revert "avocado.core: Cleanup runner->multiplexer API"

This reverts commit b6cbe734.

The 625eefe0 changed the way to fill the
adjusted/formatted test entries. The problem is, that the adjusted
entries are not the only entries the template uses. It requires other,
entries in the original format. Let's revert that part and keep the old
behavior where we only adjust the values we need to adjust.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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>