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>

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>

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>

There is a "`" missing of the in-line code and break the layout of the
document.

* https://github.com/avocado-framework/avocado:
  avocado.core.loader sort directories/files alphabetically

* https://github.com/avocado-framework/avocado:
  selftests: replace self.skipTest()
  selftests: remove redundant sudo check

Let's separate the check for requirements and the test code according to
the project's understanding of setup/test phases.

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

This was requested on avocado-devel mail list. Now the test directories
and the test files are sorted alphabetically by the test loader.

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

This check is redundant since we have a @unittest.skipIf() already
checking sudo.
Signed-off-by: NAmador Pahim <apahim@redhat.com>

There were several implementations of can_sudo methods in selftests,
most of them broken as eg. "mount" can run without sudo, which is what
happens if sudo is not available.

This patch replaces those custom methods with the one recently
introduced in `avocado.utils.process`.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Some users configure only certain commands to be available with sudo.
Let's reflect this and improve the "can_sudo" to accept "cmd", which it
tries to run under sudo.

Additionally as avocado ignores "sudo" (with warning) when "sudo" cmd
not available, this checks for it's presence.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

typo fix, ouput -> output

The utils.build prepares the env to run make inside avocado process. The
avocado.process supports various extra arguments, but to build they are
just an unrelated options. Let's avoid duplicating of process's
arguments in build and simply allow custom process_kwargs (key word
arguments) instead.

In order to keep compatibility with 36lts the original hardcoded
arguments were kept and they override the process_kwargs values, but we
should remove them as soon as the 36lts is discontinued. This will
require some changes to tests where the individual args are used.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Some processes fork daemons and not finish them. This works fine as far
as the daemons close the stdout/stderr, but there are daemons which keep
the stdout/stderr opened preventing the `process.run` to finish.

The correct response is to wait till the stdout/stderr is closed,
because otherwise we miss the produced messages of the forked processes.
On the other hand there are processes where we don't want the output and
we do want the process to finish even though the daemons spawned by the
process still run. In such cases one can use the `ignore_bg_processes`
which ignores the opened stdout/stderr and finishes as soon as the main
process finished.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

* https://github.com/avocado-framework/avocado:
  Result: remove old reference to output
  Result: change the name of the attribute to better identify the proxy
  Result: do not keep track of all of the application processed arguments
  Job: prepare for the removal of old style result plugins

The `output` attribute was, at some point, meant to hold the information
about where the result data should be sent to.  Then, the processed
arguments started to be used.

In the end, it has no purpose, so let's remove it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This is simple name change.  The goal is to make it clear that the
current "result" attribute is a ResultProxy (old style result plugin)
instance.  The idea is that a new attribute called "result" will really
be a Result instance.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

It's been a common pattern in Avocado to expose the complete set of
processed arguments to a lot of core components.  This makes the
dependencies and interfaces between these components much less clear.

As we clean up the Result class to make it just a result data container,
let's remove the reference to the processed arguments and keep track
of only the information that's relevant to a given Result implementation.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

This change combines the activation of all old style result plugins
into a single method.  It also names it accordingly, so it's easier
to spot it when it's finally removed.

Another reason for this change is that the old docstring was outdated
and inaccurate.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

avocado.utils.data_structures: add author

The loop that waits for the early test status has a call to sleep(0), which
turns it into an almost busy-loop. Changing it to sleep(0.01) consumes less CPU
without performance degradation (might actually make things run faster according
to my tests).

This change also makes it more consistent with the similar loop
for the actual test status.

On my machine, before this change running "passtest.py" 100 times would result
in almost 250000 calls to time.sleep(). After the change, the number gets down
to 600 (tracked via python cProfile module).
Signed-off-by: NAdemar de Souza Reis Jr <areis@redhat.com>

We have a loop to check for the test status which works
like this:

 status = check_status()
 while not timeout or status:
     status = check_status()
     sleep(step)
     ...

And step was defined as 0.1 (sec). At least on my machine, this was making
avocado quite slow, as it was introducing a 0.1 sec sleep between each test
execution.

This commit changes step to 0.01 secs, making Avocado respond much faster.
Notice there's no significant performance penalty with this change. sleep(0.01)
is a long time for modern CPUs and schedulers.

Benchmark is quite straighforward:

TESTS=$(for i in $(seq 1 100); do echo passtest.py; done)

BEFORE:
    $ time ./scripts/avocado run $TESTS --silent
    real    0m14.007s
    user    0m3.376s
    sys     0m3.112s

AFTER:
    $ time ./scripts/avocado run $TESTS --silent
    real    0m4.741s
    user    0m2.994s
    sys     0m2.953s
Signed-off-by: NAdemar de Souza Reis Jr <areis@redhat.com>