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