Making the path of the salt source a command line option for docker containers

[mikn]

We were looking into writing both unit and integration tests for our own custom modules and states and thought it was a good idea to be using salts own framework in as a large extent as possible, we ran into the issue that the integration tests inside a docker container required the tests/ folder for the test runner to be adjacent to the salt source code, which it wasn't for us since we deploy custom states through the salt fileserver. We applied this patch to be able to run our own subset of integration tests against the salttesting docker containers using the salt test runner.

It is a bit ugly, though with a hard coded inclusion path destination. Maybe you want to make sure that the python interpreter is reading from the destination path in question as well. Right now it is only working for Debian/Ubuntu distributions running python 2.7. Suggestions on how to best fix this are welcome!

Addresses issue #12

[mikn]

I have a couple of trials to run for the inclusion path first, actually. So hold off on merging this in until I've fixed the inclusion path ugliness. :)

[mikn]

This adds a dependency on vmware-archive/docker-containers#7, but it provides a nicer path of inclusion that should work on all containers and not just the Debian-derivatives.

[s0undt3ch]

So, right now I thinking that an extra flag should be added to runtests.py, something like --additional-test-dir?

Each of those passed flags will be checked it it's a proper path, and if it is, it will be searched for tests.

If the above works as supposed, we can also add a docker specific flag for extra mount points(maybe treat each of the values passed using --additional-test-dir as additional mount points)

With the above, docker should be made aware of additional mounts and salt's test suite of additional test directories...

Would this address your current problem?

[mikn]

Well, I don't really feel the need to run salts full battery of tests, which I would say the name --additional-test-dir would imply, and adding in arbitrary mount points would still leave the PYTHONPATH problem unaddressed, unless we added all mount points to the PYTHONPATH of course.

The reason I chose to do this way was because it is specifically dependent on the salt source code and there was no proper way to specify something to:

1. Get included in the docker container. And
2. Get appended on the PYTHONPATH.

I wanted to make it clear how to include it into the docker container without hacking the salt source code into your own repository. Though, I think you're on the right path for a proper implementation as long as it's documented as well.

Adding an option for --additional-python-dirs would be a nice first step, which would pretty much be a 1:1 replace of what I've done in these two pull requests, but be more flexible if you allowed multiple specifications of it.

I'm not sure the --additional-test-dir would be very useful if it implies running the tests in the folder though, since I would probably want to run the full battery of tests in a separate step? But I'm thinking out loud here to spur conversation. :)

[thatch45]

@s0undt3ch if this is not going to be merged we should close it out

[s0undt3ch]

A new salt-runtests script is being coded(not 100% complete) which will address the problem with running custom module tests without having to run Salt's full tests suite.

If your modules don't rely on Salt's tests state tree(because it needs some special files in it to work properly), you can take it for a spin. Checkout features/salt-runtests, change into your tests directory and run salt-runtests.

Docker support is not yet done.

Closing.