On Wed, 2018-06-06 at 11:28 +0100, Daniel P. Berrangé wrote:
On Wed, Jun 06, 2018 at 11:27:38AM +0200, Andrea Bolognani wrote:
We will probably want to do that, since installing packages takes quite a bit of time and using Docker like this apparently causes jobs to serialize, which makes shaving down time all the more important.
When I tested it, the jobs still ran in parallel. The key difference is that it causes the jobs to be scheduled on the VM based infra in Travis instead of the container based infra. There's a slightly longer startup time for jobs but otherwise nothing changes. The jobs still took approx 25-30 minutes to complete, which is the same as before this change.
Doesn't match my experience: Ubuntu jobs took 30 minutes each and the second one only started once the first one was done, meaning the whole build took about one hour to finish. The macOS job was running at the same time as the first Ubuntu job. Might have been a coincidence, though.
I'm wondering if using Ubuntu 16.04 and 18.04 as base image is the best option, however. Pavel is trying to get more hardware assigned to us in the CentOS CI environment, and assuming that's successful we will get those distributions added there as well for full-stack testing; Travis CI is more useful for developers to smoke test their patch series before posting, however, and with that in mind I think it would be much better to run the build on the latest CentOS, Fedora, Debian and Ubuntu to give reasonable coverage, leaving up to CentOS CI to catch issues related to interactions with other components or compatibility with older distros after merge.
Yeah, I just picked ubuntu as an initial target since it is close to what we have. I would like to evolve it to have similar options for coverage as the main CI. Ideally at least one of centos, ubuntu, fedora and mingw, so 5 jobs in total including macOS.
I don't like the fact that you didn't include Debian :) Ideally we'd also throw openSUSE into the mix, after adding it to the CentOS CI, but as with Ubuntu that depends on getting acces to extra capacity.
+ - docker run + --privileged
Is '--privileged' really needed here? I'm not familiar enough with Docker, but it feels like we shouldn't need it. Feel free to point out exactly why I'm wrong :)
We need privileged because we have to apt-get install extra packages. Once we switch to pre-built images we can drop the --privileged arg.
Makes sense.
- compiler: clang + language: c os: osx
You lost the ccache setting. That's probably okay because we install the package and set up PATH explicitly anyway.
The ccache setting applies to the "host", and so wouldn't have an effect in side the docker container. I guess it would still have affected ox-s though so I can re-add.
As I said it's probably not strictly necessary, but it certainly won't hurt to keep it around. Your call. -- Andrea Bolognani / Red Hat / Virtualization