One some situations, users may need to explicitly set the order in
which plugins run.  This adds support for setting the execution order
of any plugin type by using the configuration file.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Yet another utility method that returns the configuration setting
name based on the dispatcher plugin type.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

As done with `plugin_type()` let's also add an utility method
that gives the plugin's fully qualified name for a given extension.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This makes it more clear what an Avocado plugin type means.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The exact order that plugins are executed has never been explicit and
documented.  Let's use a lexical sort of the entry point name to
determine the execution order.

The entry point name is seen when a user runs `avocado plugins`, and
it's also the name used when registering the plugins (usually in a
`setup.py` file).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

* https://github.com/avocado-framework/avocado:
  Release test plan: run rpmlint on generated RPM packages
  avocado.spec: give a more informative package summary
  avocado/utils/kernel.py: remove executable support
  avocado/core/data_dir.py: remove executable support
  avocado/core/version.py: remove executable support
  avocado/utils/partition.py: remove interpreter
  avocado/utils/software_manager.py: remove direct script executable support

The commit f658f0e5 was a workaround of
the process issue fixed in 56e649ea
Let's use our library again.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  avocado.utils.process: execute default int handler

The container name was printed into "debug" log, which made the output
looks odd. Let's use the usual "info" log instead (for the UI).
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The `receive_files` is used to get the results of the execution, but it
was removed in 9d483a36 Let's bring it
back to restore docker plugin functionality.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  remote: drop directory change command on remote machine
  fix DockerTestRunner __init__() argument

Simple contrib script to find the Job results directory of a given Job
identified by the Job (partial) ID.

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

Now that we don't copy files to remote machines anymore, there's no need
to change the directory before run Avocado remotely. Actually this can
break the execution in systems that does not have the directory already
created, since the init_dir call was dropped as part of the remote files
copy removal.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Commit 295b8f61 changed attribute
names, but there is one leftover on docker plugin. This commit fixes
it.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Let's add this step to the release test plan, so that we don't introduce
erorrs and warnings to our built package.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

We're basically repeating the name of the package in the summary,
while we could add a bit more useful information.

This also fixes the following warning spotted by rpmlint:

 W: name-repeated-in-summary C Avocado
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Another instance of a non-executable file with a interpreter set.

This fixes the following errors spotted by rpmlint:

 E: wrong-script-interpreter
 /usr/lib/python2.7/site-packages/avocado/utils/kernel.py /usr/bin/env
 python
 E: non-executable-script
 /usr/lib/python2.7/site-packages/avocado/utils/kernel.py 644
 /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

* https://github.com/avocado-framework/avocado:
  remote: don't copy files for remote executions
  remote: improve error handling from remote executions
  remote: create a `DummyLoader` and use it in 'remote'
  refactor the total number of tests probe

Another possibly leftover from a time where an executable
`data_dir.py` made sense.  Let's remove it.

This also fixes the following error spotted by rpmlint:

  E: wrong-script-interpreter
  /usr/lib/python2.7/site-packages/avocado/core/data_dir.py
  /usr/bin/env python
  E: non-executable-script
  /usr/lib/python2.7/site-packages/avocado/core/data_dir.py 644
  /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `version.py` library has once used by various build scripts, as a
script, to get the version number that was set there.  This has
changed for a some time now, so let's remove the executable support.

This also fixes the following error spotted by rpmlint:

  E: wrong-script-interpreter
  /usr/lib/python2.7/site-packages/avocado/core/version.py
  /usr/bin/env python
  E: non-executable-script
  /usr/lib/python2.7/site-packages/avocado/core/version.py 644
  /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This utilility library file has no business at being executable,
so let's remote the executable interpreter currently set.

This fixes the following two errors spotted by rpmlint:

   E: wrong-script-interpreter
   /usr/lib/python2.7/site-packages/avocado/utils/partition.py
   /usr/bin/env python
   E: non-executable-script
   /usr/lib/python2.7/site-packages/avocado/utils/partition.py 644
   /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Software manager was designed as library, but it includes a simple
command line tool support.  But, besides setting a (non-portable) executable
(`/usr/bin/env python`) it also doesn't have executable bits set.

Let's remove the non-portable executable (`/usr/bin/env python`), and keep
the file without executable bits set.  If users want to run it, they can still
do it through:

 $ python -m avocado.utils.software_manager

Which is actually required in most cases because of the relative imports.
This also resolves the following error pointed out by rpmlint:

 E: non-executable-script
 /usr/lib/python2.7/site-packages/avocado/utils/software_manager.py 644
 /usr/bin/env python
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Currently, if not explicitly disabled, we copy the test files for
remote executions. This approach has a number of issues and does not
cover all the cases.

This patch removes the copy of test/multiplex files for remote
executions, making necessary for the remote instance to have the files
available in the indicated locations.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

A remote job can fail for a number of reasons other than remote access
timeout (the only error handled so far).

This patch makes the job to exit nicely, showing the message from
remote job, in case we cannot parse the json output from the remote job.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

In order to remove the hack used to fake the test_suite inside the job
when a remote execution is in place, this patch creates a new loader
class called DummyLoader, which returns the test suite with test
`SkipTest` and the file path as test name. The goal is to not engage
default test loaders when we are in a remote execution.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

Currently, the Job() is in charge to probe the number of tests. But
depending on the test runner in use, this information can be impossible
to probe before calling the test runner. For example, using the remote
test runner, we have no guarantee that the information used to create
the test_suite (test files, and multiplex files) will be available
locally, where the job is processed.

This patch transfer the probe of the number of tests to the test
runner. Also, the Result class was prepared to accommodate this change,
making the total number of tests configurable by calling
ResultProxy.set_tests_total().
Signed-off-by: NAmador Pahim <apahim@redhat.com>

In order to exit subprocess gracefully, our library overrides the
default SIGINT handler with a custom handler that waits for the
subprocess. Since the default SIGINT handler raises a KeyboardExeption,
which is expected by the caller, and our custom handler does not, this
patch calls the default handler from inside our custom handler, after
the steps required to exit the subprocess gracefully.

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

This attribute is used solely for internal purposes.  Let's make it
private.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The idfile attribute is nothing more than logdir + 'id'.  Since we've
documented this attribute, let's remove it in an attempt to keep the
job namespace cleaner.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

References to test dir and a never used test_index are Job attributes
that should not really exist.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The `run()` method is supposed to be the simplified interface for
jobs, that is, they run all phases of a job.  This should allow for
users of job instances to simply run:

   >>> job = avocado.core.job.Job()
   >>> result = job.run()

Of course the other more granular methods can still be used.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The post_tests phase is intended for the job to run any actions after
the tests are run.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The run_tests phase is responsible for actually running the test suite
that has been created in the create_test_suite phase.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This change makes the initialization of the job results happen a lot
earlier than usual, at job instantiation time.  It matches the use
cases of the "Job API", that is, when users want to manipulate job
instances.

With this, change it's possible to execute snippets of code such
as:

   >>> from avocado.core.job import Job
   >>> job = avocado.core.Job()
   >>> job.log.info("Checking if system is ready")

And have that persisted at `job.logdir`, with the "Checking if system
is ready" message logged at `job.logfile`.

This also addresses the issue that, once a job is created, its result
dir is never removed, even if it's empty.  The Avocado test runner
still behaves mostly the same, that is, if the existing job has no
tests (such as when none of the test names given were resolved), it
will proceed to the job execution.  I'd argue that, since it's not
possible (or I'd say desirable) that test resolution happens outside
the context of a job, this is the logical way to go.

This reinforces the change that a job without a test suite is still a
valid job.  That's is the reason for the removal of the test that
checked if job results directory were removed if Avocado was executed
without test names as parameters.

Reference: https://trello.com/c/hu4vxQOLSigned-off-by: NCleber Rosa <crosa@redhat.com>

The pre_tests phase is intended for the job to execute any actions it
deems necessary before any test is executed.  Right now, the Job
Pre/Post plugins have their "pre" methods executed here.

Following this, there is going to be a rename for the plugin interface
names, to better reflect that those actions do not happen before or
after a job, but happen *within* a job, before and after *tests* are
executed.

While at it, let's also make the Job Pre/Post plugin dispatcher
(`_job_pre_post_dispatcher`) private.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This introduces the create_test_suite job phase.  Its goal is to
fire up the test resolver and populate the instance attribute
`test_suite`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This introduces a skeleton for testing the use of a job
programmatically.  The most basic assumptions (such as the job id) are
tested here initially.
Signed-off-by: NCleber Rosa <crosa@redhat.com>