Recently we fixed bug where timeouts were not kept under certain
conditions, but the fix lacked selftests modification of those 2
affected selftests as they rely on test-postprocess timing.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

fix that opens compressed file in binary instead of text mode.
Signed-off-by: Nlolyu <lolyu@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

The interrupted message might be slightly misleading as there are
several timeouts before declaring the process interrupted and the wait
might not be issued immediatelly so let's use the (time - start_time)
value instead of timeout value.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

When we execute process with a timeout, we allow to specify signal to be
used after the timeout is reached defaulting to SIGTERM. This signal is
not always enough to really finish the process, on the other hand using
SIGKILL all the time might do even more damage.

Instead this version attempts to use the user-specified signal and only
if that fails it sends SIGKILL to it. The same behavior is now shared on
negative-timeout behavior.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This code is only accessible when timeout is specified so we do want to
finish as soon as possible. Let's replace the "wait" with "poll" which
might lead to declaring process Zombie even when it's not, but it's
already passed 2 timeouts so I think it's better to finish and report
something than to insist on waiting.

This improves a real bug where Avocado hanged after process execution
with timeout. This version is not the full fix, it only declares such
process as zombie and avoids the complete hang.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Our process library only allows to specify timeout for process execution
when used as the whole package using "run" method, but it might be
useful to allow the same kind of treatement for "wait". Let's move the
code there.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Recently we modified the reported xunit job name to match the avocado
job name, but this breaks the Jenkins feature that detects first failure
as it only evaluates results of the same job name. Let's allow to set
this value so people can have multiple results easily comparable.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

The "import multiprocessing.queues" results in imported
"multiprocessing".
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

The finish_deadline should be the time of the end, not timeout. This
fixes actual issue where interrupted test reports hang, because
it never checks whether the process actually lives:

    avocado run sleeptenmin.py --mux-inject /run:timeout:1
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

Signed-off-by: NJunxiang Li <junli@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Instead of relying only on the SSH status code, which can succeed
while still not leaving a usable master connection running, let's add
an explicit check.

Reference: https://github.com/avocado-framework/avocado/issues/2900Signed-off-by: NCleber Rosa <crosa@redhat.com>

The connection sharing functionality of SSH, on which the
avocado.utils.ssh.Session is based upon, requires setting control path
to be given to both the SSH holding the master connection, and to the
SSH instance that should eventually reuse the master connection.

That setting was completely absenting from the library, and the only
reason it worked, was because my local SSH configurations
(~/.ssh/config) had a default setting.

To avoid clashes (even if they could, in theory, be beneficial), let's
flag the control path for the connections initialized by Avocado as
such.

Reference: https://github.com/avocado-framework/avocado/issues/2900Signed-off-by: NCleber Rosa <crosa@redhat.com>

Starting with Fedora 30, only a minimal set of language packs are
installed on build roots, and consequently available during the build
of packages.

Some of the Avocado tests use varied locale settings, so we need the
full language packs installed.

Reference: https://github.com/avocado-framework/avocado/issues/2978
Refernece: https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildrootSigned-off-by: NCleber Rosa <crosa@redhat.com>

Some tests for the vmimage module do not specify the arch to use to
determine the image that will (would) be fetched.  It then relies on
the default of using the host arch.  But, if the test is run on a host
arch different than x86_64, the test will fail.

Let's make the test more deterministic by providing the arch parameter
value.

Reference: https://trello.com/c/92VQRMoC/1483-vmimage-tests-fail-under-x8664Signed-off-by: NCleber Rosa <crosa@redhat.com>

Commit c60f0ae8 fixed a CVE warning that GitHub sent notifications
about.  While so, it was attempted to fulfill the downstream (Fedora
and EPEL) dependencies in the same patch, keeping users of Python 2
with possibly vulnerable versions.

The matching of versions that ship in the Fedora and EPEL distros are
really best done in the SPEC file.  Finally, this was motivated by the
fact that the simple Python version check was not enough because
PyYAML>=4.2b2 is not available on Fedora 28, even though it contains
Python 3.

Reference: https://trello.com/c/3UMFOyzQ/1484-pyyaml-requirement-not-fulfilled-on-f28Signed-off-by: NCleber Rosa <crosa@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

This adds a Makefile that adds support for the Fedora COPR service to
build packages for Avocado, right out of a Git repo.  To do so, create
your project, and in "Builds" tab, select "New Build".

On "1. Select source type" section, select "SCM".  On section
"2. Provide the source", under "Clone url" add the URL of your repo.
For instance, this has been tested with:

  https://github.com/clebergnu/avocado

Under "Committish", enter a reference to a given commit.  For instance, this
has been tested with the name of this branch: "copr_makefile".

Under "3. How to build SRPM from the source", select "make srpm".
Finally, select the appropriate Chroots.  It's better not to have
"Enable internet access during this build" option checked.

Finally, it's advisable to not attempt to run this Makefile locally,
as it's designed to be run on the environment that CORP provides, that
is, a mock based chroot with super user privileges.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

Based on some reports of failures to behave properly on
unittest.TestCase's assertRaises methods, let's improve the test
coverage on these situations.

References: https://github.com/avocado-framework/avocado/issues/2791Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

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

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

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NPlamen Dimitrov <pdimitrov@pevogam.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

This change adds a new section to yaml to mux documentation about how to
inject values to the final multiplex tree using --mux-inject argument.
Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

When the Robot Framework finds an issue worthwhile to be shown on
the UI, it will do so, but that confuses Avocado users by mixing
the content from both layers.

Let's disable the Robot framework console logger, and only shown
the messages we intend to.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

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