Can one of the admins verify this patch?

@edoakes feel free to cherry pick this to release branch

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/19719/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/19718/
Test FAILed.

One problem with this change is that now it is not tested in the CI, so if we break it in a PR we won't know. See #9720

@simon-mo @edoakes

Agreed. @ijrsvt should we consider try to build the docker images (but not pushing them) in PR?

I think that building in PR is a waste of resources? It already seems like overkill to build the images in every commit. The images really don't change much because they are just dependencies and not the actual dev version of ray. That being said, I think we should start bundling ray in the image, but that may require us to use a different build infra.

@ijrsvt how much resources are we talking about?

The issue is that if we only do it in the master, then if it breaks we won't know. Ideally the PR builds should catch all of the bugs.

We also build the wheels in the CI even though they are never used.

@robertnishihara It is mostly just downloading repos and running scripts. I totally forgot about our wheel building for PRs. I think in that light, it probably isn't much harm in adding it. Is it something that we should run on all PR builds or only those affecting docker files.

@ijrsvt can we set up a separate travis job that only rebuilds the containers when the docker files are affected and always runs on master? I think that would be a good compromise.

That seems like a great idea!