This does not directly affect network because network has its own
solution for dealing with testing/linting module_utils code, but
it gets network to feature/code parity with the template and
other repos.
Defines a shell function in utils.sh - lsr_setup_module_utils -
that allows configuring a tox venv installed ansible to have
the repo module_utils code in the default pythonpath for the
venv, which allows testing and linting the module_utils code
without having to otherwise munge or mock the pythonpath.
Projects needing this functionality can set in `.travis/config.sh`
the variable `RUN_PYTEST_SETUP_MODULE_UTILS` to setup
module_utils/ for pytest, and `RUN_PYLINT_SETUP_MODULE_UTILS`
to setup module_utils/ for pylint.
NOTE: I don't think this commit directly affects network, since
network doesn't use any of these - this PR is more for parity
with template and other repos.
Centralize the setting of `ME` and `TOPDIR` in utils.sh
Add support for `RUN_FLAKE8_EXTRA_ARGS` and `RUN_BLACK_EXTRA_ARGS`
Many of the tests and tasks invoked from `tox` would try to use
the path to the `python` executable in the tox virtualenv, and
in some cases, would try to follow the symlink if the `python`
command were a symlink, in some cases, following the symlink to
the system python, and trying to use the absolute path. This
would fail in some cases because when using the system python
with the absolute path, the python modules installed in the
tox venv could not be found. So instead, just use the `python`
command from the venv with no path.
also enable travis 3.8-dev testing, since this fix allows that
platform to work correctly.
The network providers for tests_default are to be selected explicitly
Add tests_default_nm.yml
Add tests_default_initscripts.yml
Since the providers are listed explicitly ,there is no need for a other_provider playbook
Remove tests_default_other_provider.yml
Add tests_default and tests_default(nm/initscripts).yml to ingnore list for ensure_other_provider script
Molecule version 3 and later needs a different configuration file for
linters. This breaks the CI. Pin molecule to version 2 for now to
fix the CI until we have a proper fix.
Support running the molecule tests against more versions of Ansible.
By typing
LSR_ANSIBLE_DEP=<ansible> LSR_MSCENARIO=<scenario> tox -e molecule
one can run molecule inside tox with <ansible> version installed
under <scenario> scenario. For example
LSR_ANSIBLE_DEP='ansible==2.7.*' LSR_MSCENARIO=foo tox -e molecule
will run molecule under scenario 'foo' and the recent Ansible 2.7
installed. `tox -e molecule` run molecule under default scenario
with the latest Ansible (from pypi) installed.
Travis runs molecule tests for Ansible 2.6, 2.7, and 2.8 installed
and under default scenario (can be overriden by user in config.sh).
Additional changes: Remove useless comment from custom.sh.
runsyspycmd.sh script runs a given command only if venv Python
matches the system Python (this prevents failing when some command
depends on binary libraries).
Also put `molecule --version` and `ansible --version` to a standalone
testenv ([testenv:molecule_version]) so a user can display molecule
and ansible version by typing `tox -e molecule_version` without
running `molecule lint`.
Pass extra molecule dependencies via file and not via environment
variable. Also add selinux as a permanent molecule dependency
(molecule needs it on selinux enabled systems to setup containers).
Prior this change, RUN_PYLINT_* environment variables set by config.sh
have effect only while running in Travis (because runtox script sets
them by including config.sh). By wrapping pylint runner with shell
script, RUN_PYLINT_* environment variables have effect also while
running tox locally.
Some system roles want not to run black on their code. This wrapper
decides whether to run black or not depending on content of config.sh.
This wrapper also allows to set patterns of files and directories via
config.sh to be processed or skipped by black.
Not every system role contains parts written in Python, which
confuses pytest. With a shell wrapper around pytest, pytest
can be skipped or run with adjusted parameters depending on the
content or presence of system role's specific directories.
