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>

* 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>

By renaming the variables from `total_time` to `tests_total_time` it's
hopefully going to be more clear that key hold the accumulated amount of
time spent on tests.  When other time related attributes are added, such
as the total job run time, it's going to be a lot easier to distinguish
between them.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The initial versions of Avocado focused on tests, and ommited a bit
the idea of jobs.  This had the consequence of some unfit names, such
as the TestResult class, which defines methods such as "start_tests".
It's clear that a "Test" starting "tests" is either about a nested
relationship or is badly named.

Instead of replacing the name of the TestResult related classes to
JobResult, which is currently our top level player in most of the
Avocado use cases, let's just consider that this class holds the
result of what Avocado runs.  It's an abstract name, but it's not
vague because the individual attributes refer to the exact type of
information that is being held.  For instance, `job_unique_id` is
clearly about a Job, and `tests_run` is clearly about tests.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Now replay jobs will respect the original job failfast option, when used. Also,
it is possible to disable failfast option on replay jobs with `--failfast off`.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Avocado already logs when process is executed, it could be useful to
also know when the process finishes. Note it's not immediately after the
process finishes, but it's logged when avocado notices the process
finished.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Currently when the process time-outs, it's killed by default with
SIGTERM and then the status is reported. This usually results in process
returning non-zero status, which is then reported to the user. The
problem is that SIGTERM can be caught and handled inside the executed
command and it can report 0. Then the user does not know whether the
command actually finished on time or whether it was killed by avocado.

This commit sets the `self.result.interrupted`, which makes sure the
status is propagated even when the process finishes with zero.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Currently the interrution is hardcoded to be ctrl+c (signal) only. This
patch uses the `self.result.interrupted` as interruption reason, which
should allow different types of interruptions.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The interrupted message lacked '' around the cmd and ignored the
additional_text.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This patch uses Timer instead of a busy poll loop when using
`process.run` with timeout.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This method allows to query for PID of the created process.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  aexpect: add it to source and package installation requirements

* https://github.com/avocado-framework/avocado:
  avocado.utils.asset raise exception when not able to fetch asset