Remove code that modifies ansible import paths

[ssbarnea]

As part of new test-isolation strategy, molecule will no longer take
care itself about modification of:

• ANSIBLE_COLLECTIONS_PATH
• ANSIBLE_ROLES_PATH
• ANSIBLE_LIBRARY
• ANSIBLE_FILTER_PLUGINS

Test isolation is supposed to be covered transparently by ansible-compat runtime when code runs inside a virtual environment. Molecule is already using it for running all its external commands.

Related: https://ansible.readthedocs.io/projects/dev-tools/user-guide/test-isolation/

[jsf9k]

@ssbarnea - This breaks my molecule setup (and probably that of many other folks), and I'm not sure the best way to fix it. See, e.g., the most recent GitHub Actions runs from cisagov/ansible-role-assessment-tool#62 where molecule can no longer find the role that is being tested (ansible-role-assessment-tool). I'd like molecule to find and use the local version of the role that is in the code checked out from GitHub, since that is the version I want to be tested. In this case, am I now expected to set an environment variable before running molecule to add the local project directory to the role path, since molecule no longer does this for me?

In cisagov/skeleton-ansible-role#217 I tried explicitly listing the role to be tested in molecule.default/requirements.yml as a solution, but if I do that and modify the Ansible code for the role in a feature branch then running molecule from said feature branch will not pick up the local changes (since it will pull the default branch from the GitHub repo). This is obviously subpar.

If there are more changes forthcoming that will fix this then I can pin to <25.2.0 for now, but I'm not sure if that is the case.

[alix-rm]

Hello, I concurr with the above comment by @jsf9k.

@ssbarnea Could you please explain the correct way to upgrade to version 25.2.0 of molecule for the common layout of ansible-role-myrole/molecule/default?

I understand the rationale of test isolation behind the change but my feeling is that testing a local role's code is the first and most common thing people do with molecule.

I think this change could deter most the maintainers of the most common OSS roles from upgrading to this version of molecule and thus following current best practices. For instance all the geerlinguy. roles use this layout.

First thing most people will be tempted to do is pin molecule to < 25.2.0, which is probably not healthy in the long run.

Happy do discuss this and available to help easing the migration.

[remod]

We fixed it by explicitly setting ANSIBLE_COLLECTIONS_PATH=/path/to/collection before invoking molecule.

[jsf9k]

cisagov/skeleton-ansible-role#221 shows how I am intending to work around this. Very similar to @remod's solution.

[pierrehenrymuller]

Molecule and Ansible must behave in exactly the same way when searching for roles. Ansible has its own rules, and Molecule must test that Ansible will work properly in production. Changing this on the Molecule side no longer guarantees that when Ansible is running, everything will work properly.

Everything's broken with this new version, and a step backwards is imperative.

How does Molecule benefit from managing things differently?
What is the need to randomize functional testing?

Adding an environment variable to return to normal operation is not an efficient solution.

[hswong3i]

Once I revert this PR my CI case working fine again:

• alvistack@19a4df1
• https://build.opensuse.org/package/show/home:alvistack/ansible-community-molecule-25.2.0