# Custom environment for integration testing **URL:** \ **Category:** Get Help\ **Tags:** ansible-test\ **Created:** [September 17, 2025, 2:31pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509 "2025-09-17T14:31:22Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 2:31pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/1 "2025-09-17T14:31:22Z")
We want to test (ansible-test) a lookup plugin that depends on a number of environment variables existing on the controller. However, ansible-test seems to create a very limited environment to run tests in and this does not include the required env vars. Is there a supported way to customize the environment to have the needed vars? Also, we run our tests within a container that has all of the community and 3rd party collections already but our code under test is in its own directory. We’ve had to make some workarounds so that the supporting collections are found but it would be ideal if we could customize `ANSIBLE_COLLECTIONS_PATH` for the test environment instead of it being set explicitly to the current working directory. The limited documentation around this ([here](https://docs.ansible.com/ansible/latest/dev_guide/testing_running_locally.html#environment-variables)) is unclear on whether this is possible. It somewhat implies that you can modify `util.py` but that doesn’t seem like a sustainable approach. ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [September 17, 2025, 2:34pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/2 "2025-09-17T14:34:21Z")
@ljkimmz Thanks for the discussion on IRC, and taking the time to register on the Ansible Forum to ask this. @mattclay Do you have any ideas on this? They are testing a lookup plugin which works by reading various ENV options, such as AWS credentials. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 2:40pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/3 "2025-09-17T14:40:13Z")
Thank you for replying @gundalow . I was just looking for other lookup plugins that might depend on ENV vars and how they are tested. There aren’t many it seems. I did find this one and they seem to be trying to apply the `environment` keyword to the `set_fact` module/action but I’m pretty sure this doesn’t work as it didn’t work for me when I tried it. > ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [September 17, 2025, 2:47pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/4 "2025-09-17T14:47:58Z")
That won’t really do anything, as per: > **[Setting the remote environment — Ansible Community Documentation](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_environment.html#setting-the-remote-environment)** > **[Playbook Keywords — Ansible Community Documentation](https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html)** `environment` only affects modules/remote execution, `set_fact` is a ‘controller action’ and never even touches the remote, even if it did, `lookup` plugins always run on the controller (all plugins do, except modules/module\_utils). You must invoke `ansible` itself in the context of any environment variable you want plugins to be affected by. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 2:51pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/5 "2025-09-17T14:51:19Z")
Yes. Exactly. The problem is that `ansible-test` generates its own very limited environment to launch `ansible` in. Because of this we lose all of the ENV vars that we need to test this plugin. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [September 17, 2025, 2:54pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/6 "2025-09-17T14:54:32Z")
why we normally add environment variables in a `runme.sh` or use actual plays for testing that call ansible itself: ```auto - command: ansible-playbook tasks/tests.yml environment: PATH: "/tmp" ``` ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [September 17, 2025, 2:57pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/7 "2025-09-17T14:57:26Z")
Generally speaking, instead of making the integration target a role (although it could still be shaped that way), you would make a `runme.sh` based integration test target, that could set the env vars in the script, and then invoke a playbook with ansible-playbook. There are a number of examples in the ansible/ansible repo of runme.sh targets. It would not be able to rely on injecting local env vars into the test container though, you would have to use an `integration_config.yml` file to do that, and there are examples through the ansible-collections org on GitHub: > **[Build software better, together](https://github.com/search?q=org%3Aansible-collections%20integration_config&type=code)** > > GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 3:01pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/8 "2025-09-17T15:01:13Z")
Ok, the way you gents are talking about this it sounds like `runme.sh` is a common testing pattern but I haven’t seen that mentioned in any of the testing documentation. Also, `integration_config.yml` is just mentioned briefly in the docs as being useful ([here](https://docs.ansible.com/ansible/latest/dev_guide/testing_integration.html#integration-config-yml)) but gives no information on its purpose or how to configure it. Don’t get me wrong, we use this file but we’ve just had to infer things from the limited documentation and whatever examples we can find. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 3:04pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/9 "2025-09-17T15:04:32Z")
Ah, now that you’ve made me aware of `runme.sh` I do see just a mention of it in the integration test documentation ([here](https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_integration_about.html#understanding-integration-tests)). But it is only mentioned - no detail is given on its use or how its execution differs from the role-based testing. This would be super useful information. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [September 17, 2025, 3:07pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/10 "2025-09-17T15:07:30Z")
i believe that 99% of the use of `runme.sh` is done in testing ansible-core, so the community never bothered to really explain how it works for community testing. It basically runs ‘instead’ of the role and the rc of the script determines success/failure of the test. It has a lot of flexibility, but the reporting is not as good, why i tend to use the ‘ansible calling ansible’ pattern in all new tests that require it. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 3:14pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/11 "2025-09-17T15:14:18Z")
Ok, so it appears that `ansible-test` still creates a limited environment when launching the script. It’s just now we have the ability to add vars back to the environment before launching `ansible`, right? So we’ll need something to capture the initial environment into a file or script and then restore that environment in `runme.sh`. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [September 17, 2025, 3:17pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/12 "2025-09-17T15:17:00Z")
> [@ljkimmz](#): > > tes a limited environment when launching the script. It’s just now we have the ability to add vars back to the environment before launching `ansible`, right? So we’ll need something to capture the initial environment into a file or script and then restore that environment in The `runme.sh` will not push the environment up as it is run in a subshell, the same goes for running ansible from inside ansible ---
**Author:** ![mattclay](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mattclay/32/268_2.png) [@mattclay](https://forum.ansible.com/u/mattclay)\ **Post date:** [September 17, 2025, 3:54pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/13 "2025-09-17T15:54:14Z")
As of ansible-core 2.19, environment variables can be set on the controller using the `aliases` file of an integration test. For example: > This is intended for non-sensitive static values, which should be committed along with the tests. Prior to that feature being implemented, using a `runme.sh` was the best way to accomplish the same effect. If this feature would be useful in earlier versions of ansible-test, I’m open to backporting it. For dynamic or sensitive values which should not be in version control, using `integration_config.yml` is the recommended approach, since it allows you to provide Ansible variables to the test environment, even if it’s running inside a container or on a remote host. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 17, 2025, 4:05pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/14 "2025-09-17T16:05:56Z")
@mattclay the `integration_config.yml` would only be for Ansible variables and would only apply to the target(s), not the controller, right? ---
**Author:** ![mattclay](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mattclay/32/268_2.png) [@mattclay](https://forum.ansible.com/u/mattclay)\ **Post date:** [September 17, 2025, 9:46pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/15 "2025-09-17T21:46:27Z")
When `ansible-test` generates a playbook for running integration tests, it specifies `integration_config.yml` for the `vars_files` keyword. All of the variables in that file will be visible to the controller (`ansible-playbook`), regardless of where it’s running. Those variables can be used just like any other to affect module execution, whether on the controller or target. ---
**Author:** ![ljkimmz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ljkimmz/32/9446_2.png) [@ljkimmz](https://forum.ansible.com/u/ljkimmz)\ **Post date:** [September 18, 2025, 12:12pm UTC](https://forum.ansible.com/t/custom-environment-for-integration-testing/44509/16 "2025-09-18T12:12:07Z")
Thanks, all, for the input and information. It would be great to see some added documentation about the use cases for the `runme.sh` vs `role-based` integration testing patterns.