refactor travis setup

[jsvd]

rely on config imports to maximize reuse. For a plugin to adopt these scripts they only need to either add a simple:

import:
- logstash-plugins/.ci:travis/defaults.yml@travis_refactor
- logstash-plugins/.ci:travis/matrix.yml@travis_refactor
- logstash-plugins/.ci:travis/exec.yml@travis_refactor

This pull request tries to do away with submodules to reduce the effort of adoption. The exec.yml downloads a tarball with all the necessary docker and shell scripts, but skips any existing files, so plugins can customize testing.

The goal is to version the yaml and scripts through git tags, so all plugins rely on the same setup (unless it is customized).

[kares]

like where this is going, esp. since the inception some of my assumptions have aged,
namely: unit/Dockerfile was far fetched - having one shareable Dockerfile should do.
+1 on composable .travis.yml imports - likely easier to reason than merging 2 ymls.

only thing I have doubts is downloading the .ci repo instead of the sub-module check-out.
just from browsing the single repo on GH we won't be able to see all the CI build parts.
willing to give it a try on a few repos and see how we like it compared to a sub-module.

[jsvd]

I have updated the PR to reduce the scope (drop auto publishing).
Here are a few examples of adopting these configurations:

• http output: use central test setup on travis logstash-output-http#108
• date filter: move testing to travis centralized configuration + auxiliary fixes logstash-filter-date#135
• udp input: use central test setup on travis logstash-input-udp#49

[kares]

out of curiosity, is there anything we might need the system installed ruby for?

[jsvd]

not really, the travis config parser complains about us not setting any lang, we can also set this as generic

[kares]

there's also language: minimal (has Docker available) which we used before

[kares]

🏆 for plugin CI testing.
we need to change the branch name, not sure whether to start tagging right off or just use master