Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature/travis docker #894
This is still somewhat experimental, but it is now the third GitHub repo where I tried this with success.
In essence, we convert Travis to 'bring your own container' which is quite powerful as the CI runs now become portable. By relying on a Docker Hub container, the same test could run at GitLab, or on your computer, or anywhere else.
Plus, by relying on containers we open up for easy / easier test matrices with r-devel, r-olrel, r-rchk, r-ubsan, r-with-different-compilers, ... Truly endless possibilities.
[ The old system worked well for us too, but I need to update it as well to at least get us to using R 3.5.x (and it is a bug in my r-travis repo that we're not yet ... but I have some setups still relying on PPAs built against R 3.4.x -- but different bug in different repo. ]
Thoughts or comments on this?
Thanks for putting this together!
Does this also imply improved build / test times? (Presumedly this means we can reuse a prebuilt Docker image for testing?)
Is there any worry about the Docker images becoming 'stale' as e.g. apt repositories are updated? How do those updates get incorporated into the image?
I wondered about the timing too! It seems rather comparable -- but it is a small sample so far. As of right now we have three different repos using this approach:
You should be able to find the Travis histories from thre repos to look in more detail, else I can add links here.
The one metric I looked at was
Next, the staleness could be a concern but a) the "public" (to us, in the same PR) Dockerfile coupled with b) the Docker org I set up should alleviate that. You can have Docker containers rebuilt on each commit (that is even the default). That is probably overkill here as we depend only on R and little else. We can always trigger rebuilds, or have
And ... you could argue that it is better because
And there are a few other possible upsides to going Docker: easier build matrix across R releases, compiler versions, maybe ubsan / rchk if we care etc pp.
I think this has a lot of potential but I don't want to rush this.
So let's try to find some other reasons "not to do this" so that we're sure. What else can we think, and of course which of my arguments above do you find unconvincing?
I would agree that the upsides far outweigh the potential downsides.
The only other possible concern I can think of is whether we could bump into some kind of issue that reproduces within a Docker environment but not in a plain old virtual machine, but it seems like those sorts of issues are effectively non-existent nowadays unless you're doing really low-level Linux-y stuff (something Rcpp doesn't do).
Either way, I think it's worth sleeping on this for a couple days in case some compelling blocker does come to mind but overall I think this will be a net positive.
Sep 2, 2018
@kevinushey I still wonder about the timing though. We can't control for load at their end, networking etc so a quick local comparison:
and I alternated (ie normal/Docker/normal/Docker). So I guess it is a tie, and Docker has no real discernible cost.