Avocado: Update to release 0.25.0

Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Update the manual page regarding wrapping process, we're using
the shell-like style to select the process to wrap on scripts.

The documentation explains the previous behavior, before
the commit f6bf2c02Signed-off-by: NRudá Moura <rmoura@redhat.com>

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

avocado.Test cleanup: low hanging fruits

The extra line was confusing, therefore, we shall remove
it from the logs.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

As as way to give `avocado.Test` users (test writers) a better sense of what
is the API allowed/intended for their use.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As as way to give `avocado.Test` users (test writers) a better sense of what
is the API allowed/intended for their use.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As as way to give `avocado.Test` users (test writers) a better sense of what
is the API allowed/intended for their use.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As as way to give `avocado.Test` users (test writers) a better sense of what
is the API allowed/intended for their use.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

When wrapping process, the parameter for a local wrap is defined
by using a shell-like glob interface (*make for example).

So remove the parts that mentions the old behavior (absolute
 and relative paths comparison), before the changes
introduced in commit f6bf2c02

Also, drop obvious and thus useless comment about the wrapper when
it's expressed as a relative path
Signed-off-by: NRudá Moura <rmoura@redhat.com>

Log the information about the data directories being
used by avocado for that particular job run, with the
customary notice that avocado will use defaults in case
some directory in the config files is not accessible.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Log the --tree view to the job log, whenever we have
a non empty representation of that.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Add a 'root' attribute that contains the TreeNode object
of the multiplexer tree inside the Mux object. This way,
we can log the multiplexer tree in the job log.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Due to this new feature, remove the previous 'show
plugins that had problems to load' feature', given
the overlap between the two.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Dump all the configuration values being
used at the moment by avocado.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Add the avocado version number to the job debug info,
and if we can identify this directory as the avocado
source directory, also print avocado git repo info.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

So that people can easily read, copy and paste the command
lines into their terminals.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Let's move the job debug information logging to private
methods, in order to organize the code better.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

With the new information that is going to be added to
the job log, keeping up with the number of lines of that
log is a fool's errand at this point. Let's drop the checks.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

We recently updated that representation.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

Update the man page with new options on the multiplexer.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>

multiplexer: Change the --mux-entry to --mux-path

--mux-entry was a bit confusing as what it does it splits the result
params into multiple slices and while quering for keys they are
evaluated in the specified order, thus behaving the same as Linux PATH
bash variable.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

API Review (5th round) - Fixed

This module depends closely on the, already moved, avocado.core.remoter
module. Let's move it along.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The reason for the chosen name is that avocado.core already has a
remote module (directory) related to (remote) TestRunner and
TestResults.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

One of the possibilities when Avocado delegates the execution of a process to
the utility library process is undefined behavior.

This can help, for example, when this library is set to run processes in more
complex environments, including with users manipulating these process inside
debuggers.

Previously, we would have the process utility module with knowledge about
an Avocado internal exception that flags that a test should exist as SKIP
in these circunstances. Now, to avoid these prior knowledge and layer
violation, let the user of the API register which exception should be
raised when such situations occur.

A more complex version of this change, deemed unnecessary for now,
would be to register callbacks which could, in turn, raise those exceptions.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

While still making the VERSION symbol available in the top level
Avocado module. Even though this is very simple information that
could live under the avocado module itself, it would break the
consistency of having avocado.core importing from avocado (toplevel).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The runtime module had already been diminished by moving some of its
well, runtime configurations, directly to appropriate modules.
The still standing runtime configurations are: current test and
current job.

It's clearly *not* the best design to have common utility modules,
that is, avocado.utils with *knowledge* about the inner workings
of an external entity such as the Avocado Job and Test classes.
It would be much better for Avocado Job and Test classes to
register hooks/callbacks with the utility methods in a agnostic
way.

Since some of the utility modules were not designed as external
entities, the coupling is still pretty tight, and some more
profound API changes would be necessary.

For now, our goal is to avoid the crossing of boundaries when it
comes to importing and using modules, having a sane, layered approach.

The next level, still pending, is to remove this knowledge dependency
and make the utility code trully generic.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Instead of having a "common ground" that two namespaces would import and
share runtime information, let's just make the plugin set the defaults
for the module.

This is the same approache used for the GDB utility module.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Instead of having a "common ground" that two namespaces would import and
share runtime information, let's just make the plugin set the defaults
for the module.

This is quite appropriate, both regarding the namespace where the
configurations are kept (in the avocado.utils.gdb module itself) and
also regarding the single direction of module layering.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This check is being added to both to checkall and to travis.yaml,
s o that either in local and remote (CI) checks this can be quickly
flagged.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

So that it doesn't match when we look for out of boundaries imports
throughout our code.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Modify the path when running as standalone test.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>