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>

If one is running avocado as a privileged user, the "usable_ro_dir()"
function may create a system wide directory for hosting tests.  That's
confusing because, the following workflow is possible:

 1) Regular user creates test, say "foo.py" in his own test dir
 2) Privileged user run "avocado run does_not_exist.py", which by
    means of "usable_ro_dir()", may create a system wide location
    for tests.
 3) Regular user runs "avocado run foo.py", and then test is not found
    because "avocado.core.data_dir.get_test_dir()" gives precedence to
    the system test dir created earlier.

This is also a problem when running the selftests from within the
tree, when working as a privileged user.  And finally, as a general
rule, we should avoid creating directories in system-wide locations so
silently, so I do believe this pattern could be expanded to the
results and data directories too.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

1. read directly from /proc/meminfo.
2. improve the regex to get more accurate result.
Signed-off-by: Nlolyu <lolyu@redhat.com>

As a documented feature of the asset fetcher, a user may want to make
sure, by the use of a hash, that the fetched asset is sound.  Also, by
giving a name of the asset, allow it to be fetched from a different
number of locations.

But, there's a difference in intention when a name+hash is used, and
when a specific location and hash (a URL+hash) is used.  In the later
case, we don't want to cache the file by name, because different URLs
can have completely different contents.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The name the user gives to the asset fetcher should be the primary
controlling aspect of the cache location.  The possible locations
where the asset might be found are just an aiding component to the
asset retrieval.

This is, besides a fix, also an opmization, given that
_get_relative_dir() is now called only once, instead of once for each
possible location.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The definition of the locations parameter feels broken.  Let's improve it.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

This changes addresses the CVE-2017-18342[1] that defines: "In PyYAML
before 4.1, the yaml.load() API could execute arbitrary code. In other
words, yaml.safe_load is not used."

The change affects only installation using Python 3 because when
building EL7 RPMs, we want to use version 3.10, which is packaged on
EPEL.

[1] - https://nvd.nist.gov/vuln/detail/CVE-2017-18342Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

According to the author of the publication, the authoritative source,
we were using an incorrect URL to the publication that backs the CIT
implementation.  Let's fix that.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

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

This change adds a new utility function that receives a process id and
returns all processors (id) being used by the process (and its threads)
informed.
Signed-off-by: NCaio Carrara <ccarrara@redhat.com>

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

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

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

During the "make existing file tests" process of File Loader discover
method a broader exception is used because a lot of problems can be
found in this point. Regarding Python files, any exception can be
raised. When one of those exceptions was raised, the method
`_make_simple_or_broken_test` was being called without the third
parameter. This bug was added by the commit "cd818a8a".

Reference: https://trello.com/c/ggH77dKBSigned-off-by: NCaio Carrara <ccarrara@redhat.com>

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

The "discovery" with/without class_name given are really different
use-cases. Let's split them. Currently that means lots of redundant
code, but it'll allow some cleanups later.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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

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

* https://github.com/avocado-framework/avocado:
  plugins.xunit: Format 'time' with 3 decimal places

Let's print the default value of --xunit-job-result option
on CLI help text.
Signed-off-by: NWainer dos Santos Moschetta <wainersm@redhat.com>

Any xUnit XML file when used to import test results in Jenkins CI
must comply to Ant and Maven's xUnit format specification. From
Jenkins' xUnit version 2.0 and up, the floating-point representation
of 'time' attribute should match Maven's surefire format
that restricts the use of at most 3 decimal places. But the Avocado's
xUnit plugin renders the 'time' attribute with several decimal places,
resulting in error to the load results.xml in Jenkins.

This change solves that problem by ensuring that the 'time' attribute
in Avocado's results.xml file is formatted with 3 decimal places.
Signed-off-by: NWainer dos Santos Moschetta <wainersm@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: NCaio Carrara <ccarrara@redhat.com>

Common location for contributing guidelines is "./CONTRIBUTING*" and
even github encourages us to use it. Let's symlink our documentation to
simplify first-time contributions (and also to make github happier).
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

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