Move from Travis to another CI provider

[mmarchini]

The latest kernel we can use on Travis is 4.4, which prevents us from running our runtime tests suite there. Since these tests are pretty useful, I think we should consider moving our CI somewhere else.

AppVeyor supports non-containerized Ubuntu 18.04, which means we can run our runtime test suite there: https://www.appveyor.com/blog/2018/09/18/ubuntu-1804-bionic-beaver/

There's also https://buildbot.iovisor.org/jenkins/, but I don't know how to setup jobs there.

I would like to try AppVeyor first, and if that doesn't work we can move to iovisor Jenkins.

[fntlnz]

Subscribing to this issue because kubectl-trace will likely need to follow bpftrace in this decision in order to get consistent results in tests.

[mmarchini]

I had another idea: in theory we could use docker-machine to provision hosts in some cloud provider. The only problem (besides cost) is that docker-machine doesn't support exporting/importing machines, so we would need to either use an workaround (which might break in the future) or create/destroy for each Travis job (upside: would cost less, downside: build would take more time).

[mmarchini]

I played with this idea a bit. docker-machine is not the appropriate tool for the job (unless we want to provision and destroy machines for each job), it would be better to use docker -H ssh://user@host build/run ..., but the Docker version we have available on Travis doesn't support hosts via SSH. So, there are two options:

1. ssh + run docker on host
2. Make an ssh tunnel for the Docker Unix socket from the host to Travis

There's a lot of small details here though (need to copy the repository to the host, make sure directories are correct, etc.), so this is not trivial. But it's possible, and would be a way to run newer Kernels (and even different platforms, such as arm) on Travis.

The biggest problem is that Travis don't export encrypted variables and files to Jobs running for Pull Requests opened from forks, which means we wouldn't have access to the private key for the host, thus we wouldn't be able to run those jobs on these PRs (we could still run them on master daily, for example).

Overall I think this idea (using an existing CI and running the tests on a separate host) might be more trouble than we want to deal with for now, but it's nice to know this is a possibility.

[mmarchini]

Travis now supports Bionic (for a subset of languages). I'll try to update our Travis setup to see if we can use it on bpftrace.

[fbs]

@mmarchini looks like this can be closed?