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>

The `expire` argument was added later and there are usecases where it
was not used. Let's use default which keeps the original handling, which
is unlimited expiration.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The main change is actually incorrect, the kernel.py library uses
`data_dirs` argument to determine the `cache_dirs`, which is by default
`self.work_dir`.

This reverts commit 36ea7be6.

avocado/utils/kernel.py: fix the use of the asset library [v2]

avocado/plugins/journal.py: make the goal of this plugin more clear

We found some users of this plugin, and we're unsure they actually use
this as intended.  Even if they don't use it as intended, it may be a
good thing, *but* we should make it clear what was the original goal
of this feature.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And the docstring of the asset library itself.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Use the avocado.utils.filelock to avoid race conditions:
 - Download the files with a temporary unique name.
 - Lock the original file.
 - Move downloaded file to the original name.
 - Compute the hash, creating the hashfile.
 - Verify the file against the provided hash.
 - Unlock the original file.
 (While the lock is acquired, users trying to use the file will wait until
 the lock is released or, on wait timeout, receive a cache miss)

Drop EnviromentError exceptions on cache miss. Instead, we now only
log an error message and return None.

Clean debug messages. Log was being polluted by asset fetcher. Let's
make it quieter.

Reference: https://trello.com/c/NeFPMkZY
Reference: https://trello.com/c/OWCprQpdSigned-off-by: NAmador Pahim <apahim@redhat.com>

This is a general purpose file locker.

If the lock file already exists and it contains the current process
id in it, we wait until the timeout for the lock to be released,
raising an AlreadyLocked exception when the timeout is reached.

If the lock file already exists and it contains a pid of another
running process, we raise an AlreadyLocked exception.

If the lock file exists and it has no running processes pid in it,
we try to clean the file and acquire the lock, raising a LockFailed
exception when something goes wrong.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

This allows `AVOCADO_SELF_CHECK=1 ./selftests/checkall` to run
inside virtualenv environemnts.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Fedora 24 using screen has TERM=screen.xterm-256color. This patch adds
that terminal option in the list of valid options to be colorized.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

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

Those test runners are implemented as TestResult classes, so they may
also signal their intention to use stdout.  If they don't, both the
RemoteTestResult/VMTestResult and HumanTestResult will end up using
the stdout.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The docker cleanup can sometimes fail, which masks the original failure.
This patch catches all exceptions and only log them to UI as warnings.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The `docker run` command can actually take longer, when pulling the
image from hub. Let's remove the timeout completelly.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The `docker run` command can actually produce several lines of output
(eg pulling the image) before it writes the container id. Let's use only
the last line when getting the cid.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The cleanup fails when the remote docker connection is not established.
This skips the cleanup when the resource was not yet created.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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

* https://github.com/avocado-framework/avocado:
  avocado.core.runner: Remove the unused setup/tear_down methods
  avocado.core.remote: Style fixes in runner
  avocado.core.remote: Improve the `tear_down` execution
  avocado.core.remote: Improve VMTestRunner tear_down method
  avocado.core.remote: Handle urls without assigned files
  avocado.plugins: Add plugin to run job in docker container

The `setup` and `tear_down` methods are defined in `TestRunner`, but
they are not handleded, nor used by it. This is dangerous, because even
from description they give the impression, that you can simply implement
them and they'll magically does the job.

Those methods are used inside `RemoteRunner` and they should only be
defined there.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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

For some reason the RemoteTestRunner's tear_down is only called on
`setup` errors, or after the testing. This patch removes the special
handling and adds the `tear_down` into `try/finally` block starting with
`setup` and ending when the testing is done. This should make sure that
we always run `tear_down` in RemoteTestRunner.

This means there is no need for special handling in `VMTestRunner`
anymore so it has been removed too.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The tear_down method can be currently called even before the `self.vm`
is initialized, producing an ugly traceback. This patch only cleanups
the vm when it's initialized and undefines it afterwards, so multiple
runs won't restore the snapshot multiple times.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The remote runner url=>file is rather simple, it takes the url and if
the file does not exists, it uses test_dir + url. Fabric should copy
that file, but it silently ignores missing files, therefor (unless the
file already exists on the remote machine) it fails later in the code
with "Unable to discover ...".

This patch adds check to make sure the mapped file exists. If not it
raises exception.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Similarly to --remote or --vm plugins this plugin allows one to run the
job inside a docker container by specifying the docker image. It
executes a new container, then attaches it and uses it similarly as
--remote plugin uses remote machine.

To check it out you can use "ldoktor/fedora-avocado" image which is
available on (the default) hub.docker.com
Signed-off-by: NCleber Rosa <crosa@redhat.com>
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>