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>

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>

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>

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>

Add options --env-keep to run command so users can make
available in remote executions of Avocado some environment
variables that are available locally.

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

This patch adds simple TAP (v12) results plugin. It supports stdout/file
output and is fully stream-lined (uses 1 line buffering to file).
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

There's no reason for having a separated simpletests directory, let's move
them to the tests directory.

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

This script introduces a pair of directories that will be searched
for executable files, to be run before and after the actual execution
of a job.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Avocado's setup.py used to not be based on setuptools, but plain
distutils. Then, it wasn't possible to use 2to3 when to help with
Python 3 automatic adjustments.

Since 333e439b it's now based on setuptools so we can enable 2to3.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

job replay support using the run option "--replay "
implements the job replay, retrieving the original job urls, multiplex and
configuration.

The option "--replay-test-status " is fully functional,
allowing users to replay only the variants that faced a given status in
the original job.

To ignore some original job information, the option
"--replay-job-ignore " can be used.

Notice if can inform the urls and/or the multiplex using the command line.
The options informed in the command line will be used, making the replay job ignore
that information from the source job.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Including the old base plugin class definition.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

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

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

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

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

Yes, too many plugin mentions, in this commit title, but that's what
it really is, so please bear with it.

Now that the plugin types have a finer granularity, let's show each
plugin type (based on the namespace) as a separate section.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@scylladb.com>
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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

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

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

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

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

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

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

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

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

In module avocado.core.plugins.builtin, There is a calling of
os.listdir() to iterate files in the installed python directory.

If avocado is installed in an .egg file which is compressed, it will
fail to load because that path does not really exists.

To avoid this failure, this patch set zip_safe to False explicitly.
So setuptools will install package to a real directory instead of a
zipped .egg file.
Signed-off-by: NHao Liu <hliu@redhat.com>

One standard setuptools command is "test". That command does some useful
setup and then runs the test in a verbose mode.

There are a couple of reasons for activating that, including that
setuptools can help us support a Python 3 version of Avocado by
running 2to3 and even custom fixers before running the tests, or even
builds and installs.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This fixes #628.

Add a couple of simple shell scripts that can be listed
and executed with avocado. Let's update our documentation
to use this new dir and avoid people confused with our
wrappers.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@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 new location was not reflected on the setup.py script, resulting
in the module not being present after installation.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The initial idea about the avocado.restclient namespace was that
eventually users could write scripts using that as an API to
interact with avocado-server using Python code.

While the idea is still valid, the avocado-server interface is
a simple and standards compliant RESTful interface. Thus, users
can still easily interact with it without us having to support
a formal Python API at this point.

In the future, if need arises, we can improve the Python REST
client API and promote it to a public namespace.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

And while doing that, also remove avocado.linux for good, since no one else
lives there.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The GDB config file was not being installed and packaged in the RPM
package. This should fix it.
Signed-off-by: NLucas Meneghel Rodrigues <lmr@redhat.com>
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NRudá Moura <rmoura@redhat.com>