When using `--remote-no-copy` the test files will neither be copied from the
current system nor executed on it, so disable all sorts of checks.

This is a fix for the local check only. A more complicated issue is to perform
similar checks on the RemoteTestRunner and report possible failures in a clean
way.

This address the github issue #417.

Changes from v1:
* Use a simpler Python idiom (getattr with default instead of hasattr and
  extra check). Spotted by Rudá Moura.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado.test: Little speed optimization of the warn log

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

  self.job: Command line options in "jobless mode" [V2]

Fix avocado runner problem when running avocado from the base package.

The current way the text was built looks bad while
looking at the docs in the browser.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

* Include `avocado.module` inside setup.py.
* Check if htmlresult plugin is installed from the import,
  to set the HTML result feature on or off.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Share functionality of remote and vm plugins inside the  new submodule `avocado.remote`.

avocado.test: Fortify avocado before very nasty exceptions

The NastyException error is back:

class NastyException(Exception):
    def __init__(self, msg):
        self.msg = msg
    def __str__(self):
        return self.msg

crashes Avocado. The problem is we are trying to re-raise the exceptions
and then read the traceback again. Even reading of the details of this
very nasty written exception causes critical failure.

What this patch does instead of handling issues wherever we produce
them, it waits till the exception bubbles to the entry-point and it
tries to read it. If it fails, we log the original traceback
(information about the failure) and then user-friendly message saying
we're unable to retrieve the original failure.

Additionally I had to modify the xunit output as in case of very nasty
inputs it's unable to reproduce the values.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

From the Job class, put the previous `standalone` argument
inside the `args` environment, so the class now requires only
one argument args.

For completeness, the Job class will always contain an `args` defined,
even if we don't pass anything, it will contain an empty environment,
so that we don't need to check if job is None and it will always be
possible to use `getattr()` to get an attribute from `args`.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Since the API creates a directory (instead of just return the name),
rename `get_job_logs_dir` to `create_job_log_dir`.

Use a proper parameter to get the base dir, instead of passing
the whole `args` environment for that.

As a matter of style, `avocado.core` should avoid to use `args`.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

When running tests in standalone mode, allow some command line
options to control the test execution.

Currently only an option to keep the logs after test
execution is implemented.

The class `avocado.job.TestModuleRunner` is now `avocado.job.TestProgram`.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

examples.tests.doublefree: Change behavior to expect success/pass.

  REST Client: introduce API and avocado-rest-client application [v4]

Update the unit test for remote and vm functionality to use the
new submodule `avocado.remote`, regarding the changes made so far.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

The RemoteTest is now on `avocado.remote.test` module.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Since the new `avocado.remote` contains the core functionality of
remote and vm, clean these plugins to use this module, so it now contains
just the command line options.

So it would be possible to create a proper subproject in the future.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Create a new submodule `avocado.remote` containing the core aspects of
`avocado.plugins.remote` and `avocado.plugins.vm`.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Change behavior to expect the test to pass, by using test asserts.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

We declared that WARN is only a special case of PASS,
we should probably return exit code 0.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

A command that inspects the server status and available functionality.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Introduce a new command line application that is designed to interact
with avocado-server.

Changes from v1:
* Fixed reference in the docstrings to arcli (from arc)
* Release number bump on spec file
* Add missing avocado.restclient.cli.actions module to setup.py
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado-server has been given the functionality to list the APIs
that it serves, and this code adds a simple connection method and
an example script to use that.

This should allow clients to dynamically adjust to available APIs.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

To actually perform any online task, one needs a valid connection
to an avocado-server. This introduces the connection module, along
with API examples on how to use them.

This functionality is configurable by default using the standard
avocado configuration file, so reasonable connection options are
set.

Changes from v1:
 * Be more specific with exceptions during connection initialization
Signed-off-by: NCleber Rosa <crosa@redhat.com>

An essential part of a client interacting with avocado-server is to handle
the reponse of a request. The most common type of response type is a
results reponse, when one performs a GET to a resource "root" path and
and expects to return a list of resources.

To make that more pythonic, this commit introduces a ResultResponse class
that accepts the JSON response data and checks for completeness. If
results response fails to comply with the required data members, meaningful
exceptions will be raised.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

This patch simplifies the concept of WARN test. In case user uses the
self.log.warn or self.log.warning methods, test is marked as dirty and
in case everything else worked fine it finishes with TestWarn exception.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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

This example demonstrate simple usage of GDB API.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

A few contributions to examples: bind_cpu0, cabort and raise [V2].

Manual Test Plan

Add new test `raise.py` to raise signals to itself and check results.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Add new test `cabort.py` to call abort() from lib C.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Add new wrapper script `bind_cpu0.sh` to bind process to CPU 0.
So it will force the process (and its children) to run in one CPU.
Signed-off-by: NRudá Moura <rmoura@redhat.com>

This test is using the location of the source file as the build
location, instead of the `srcdir` provided by the Test class.
Signed-off-by: NRudá Moura <rmoura@redhat.com>