I'm not sure this is a bug in the pipeline, this is how ansible works: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#ansible-configuration-settings

maybe you could rename the file and when you want to use it set the ANSIBLE_CONFIG ?

Yes, that's how ansible works, I agree.

I did that in my PR, I renamed the file.

But the problem still persists: the pipeline is using my personal configuration even when I think it shouldn't - it was easy to break the CI run and I believe you spent some serious time on investigation of the real cause. What if something similar happens in a month when someone else commits their ansible.cfg in the tests dir and the pipeline breaks in a completely different way.

This is why I think that pipeline should not pick custom ansible cfgs up: it should delete it, or rename it, or have its own ansible.cfg.

Feel free to close this as wontfix, but to me if feels like this issue makes the user experience not ideal.

@bgoncalv should we close this out or is there something you think we could do to help? it feels to me like it's an ansible limit and we can't do a whole lot, but I'm open to ideas. :)

@jimbair I could change the pipeline code to rename or delete any ansible.cfg on tests directory, I just don't know if we should actually play with file content form the repo. If more people in the team agree with us deleting or renaming local ansible.cfg file I'm fine to fix the pipeline code.

@bookwar @msrb @astepano @mvadkert what is your opinion? :)

https://docs.fedoraproject.org/en-US/ci/standard-test-interface/ supposes that context for ansible-playbook is the dist-git dir with tests. If maintainer put something to that directory that can influence Ansible that is on maintainer responsibility. @ttomecek if you want it is possible to add to https://docs.fedoraproject.org/en-US/ci/standard-test-interface/ explicit phrase: that is dist-git with tests is context directory for running tests and can influence Ansible behavior . CI pipeline just cannot cover all possible cases and guard context dir that changes Ansible behavior.

-1 to deleting or renaming user files :)

Alternatively, we could explicitly set ANSIBLE_CONFIG in CI and point it to an empty config file. That way the config in dist-git repo would be ignored (in CI).

But this would widen the gap between CI and local runs, which is not ideal.

I agree with not touching the source we pull down to test; if we want to explicitly ignore any ansible configs in our pipelines, we should do so within our code.

To @msrb's point, would there be use cases where a developer would provide an ansible.cfg for our tests that we should respect? If yes (or if yes in the future), then we may need to add some logic to inspect the config and only ignore if used for local tests like we see here. If we never want to use anything but our own ansible configs, I like the idea of explicitly setting our configs, making sure we ignore configs in git, and documenting this "gap" so devs aren't surprised (perhaps in a "how to run these test locally" section?)

Just my thoughts. :)