Improve CI test script to do something more meaningful

[gobengo]

Do this #TODO https://github.com/sudomesh/exitnode/pull/14/files#diff-098f6bcd4621d373cade4e832627b4f6R5

# TODO: test exitnode thoroughly
# ideas:
# * test systemd service files for syntax correctness 
# * run create_exitnode.sh in a docker container, then make sure it runs well`

Why?

• All future changes to this repo will have that test script run and clear to code reviewers and stuff
• Less buggy code is released
• Network more stable

[eenblam]

1d0e0e8 adds shellcheck to ensure POSIX compatibility. Nice improvement, but it would be nice to actually deploy some stuff. Working on a Vagrant configuration so folks can conveniently test on a local machine before pushing, then I'll try to replicate that for our CI pipeline.

[jhpoelen]

@eenblam please note travis-ci/travis-ci#6060

[eenblam]

@jhpoelen Good looking out! We should be good, though - I'm not trying to run Vagrant inside of Travis. I just want to make it super easy for folks to run local tests on a clean Ubuntu/Debian/whatever image, just as if they were deploying to a fresh server. The remote pipeline will run the tests in a slightly different environment, which is somewhat suboptimal but I think an easy win for the short- to medium-term.

[eenblam]

NB: We might get better logs by moving the call to shellcheck directly into .travis.yml. I'll play with this by forcing shellcheck errors in a dummy branch.

[jhpoelen]

Re: vagrant - Sounds fun and complicated. In my experience, tests makes sense if they are fully automated. Why not just deploy to a droplet and test with a tunneldigger client?

btw - the dummy ./test script was created by @gobengo and I wanted to honor his contribution by adding to it.

[eenblam]

I'm not proposing removing ./test, as I hope our tests are deeper than .travis.yml can support. I just meant to point out that shellcheck is just a quick linting step.

Vagrant is as easy as vagrant up && vagrant ssh -c /vagrant/test to run tests locally. I'm not sure how "deploy to a droplet and test with a tunneldigger client" is more fully automated in some way. Happy to work towards a mutually acceptable workflow, of course. Maybe a good time to chat in person? :)