Set up continuous integration with Travis

[hydrosquall]

• Sets up a basic integration test as requested in Setup continuos integration #13
• Unclear to me whether the failures in python3 is an issue with the CI setup, or a genuine incompatibility with Airflow 1.9. (You can check the logs yourself and decide: https://travis-ci.org/hydrosquall/airflow-exporter/builds/442006992)

Things to watch out for:

• I have to run the Airflow1.9 test as a root user, because for some reason Airflow Webserver seems to be writing logs with a different user than it was doing in Airflow1.8.

Based on the travis log messages when running in non-detached mode, I believe the issue is that the user inside the container is unable to create new folders on the host machine. (example, search for permission denied).

I tried a couple different options to get around this issue, but this seemed like the cleanest.

Other possible extras:

• Do we want to be stricter about what constitutes "valid" input besides returning 200 status code? (A strict text match doesn't make sense since the memory values would be a little different every time). I think there's room to improve, but that this could still help as a first-pass.

• Does epoch8 have an organization Travis account? For now I'm running the CI jobs on my personal account, but you can use this same config file to tie the tests into your organization account: https://travis-ci.org/hydrosquall/airflow-exporter

[elephantum]

@hydrosquall yesterday was a big day for bugs squashing, may be if you update to the latest master 1.9 will work for you.

[hydrosquall]

@elephantum I think I am branched off the latest commit (c2af12e), but still getting this result.

I left in some commented-out code for workarounds I tried (mostly setting chown in either the dockerfile or bash script) but they don't seem to have had the desired effect.

[elephantum]

@hydrosquall I'll take a look this evening

[hydrosquall]

@elephantum - I talked about this with my coworker @yegorski, who came up with an alternative to running as root. Instead, we use the user ID of the travis worker who is running the docker service, which feels slightly safer. I put that into the latest commit that has been pushed up.