-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
TST : first pass updating to use travis containers #4355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This will not work currently, waiting on travis to whitelist needed packages.
Apparently the container-based tests start faster and run on better hardware. |
@meatballhat Thank you for the prompt response! |
This seems to have odd intermittent latex-related failures (but enough restarts fixes it). |
The issue above is that to install humor sans we need to enable debian-sid as a source, but if we do that then we get newer versions of a bunch of other stuff, which sets off a nastier dependency cascade which results in failure to install the apt related packages. @jenshnielsen Does humor sans just get used in building the docs? |
@tacaswell actually we don't need sid for that, it exists in |
the travis build are ubuntu precise so I suspect even those channels would cause trouble |
Dumping error, restarted test, only on 2.7 this time.
|
Travis build machines only have 2 cores
Well for debian, backport packages have a higher pin and thus don't install unless you force it to install from backports, or you can try getting it from utopic http://packages.ubuntu.com/search?keywords=humor+sans&searchon=names&suite=all§ion=all Only a font file so you might not even need to download it from the sources. Looking at the website, all the example figures get generated using the font, so yes, to generate those figures you will need the font installed. see http://matplotlib.org/xkcd/examples/api/barchart_demo.html |
I ended up just grabbing the .deb, unpacking and then copying it to the correct place to be found by fc-cache. |
Well it worked! |
@tacaswell Yes it is only used to build some of the xkcd and font examples. I'm 👍 on installing by hand. |
Looks like google font has moved to github so we should probably change the Felipa-Regular download location to https://github.com/google/fonts/blob/master/ofl/felipa/Felipa-Regular.ttf?raw=true (That was the best free Cursive font that I could find) |
@@ -25,8 +44,7 @@ matrix: | |||
|
|||
install: | |||
- pip install -q --use-mirrors nose python-dateutil $NUMPY pep8 pyparsing pillow sphinx!=1.3.0 | |||
- sudo apt-get update && sudo apt-get -qq install inkscape libav-tools gdb mencoder | |||
# We use --no-install-recommends to avoid pulling in additional large latex docs that we don't need | |||
# We use --no-install-recommends to avoid pulling in additional large latex docs that we don't need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was referring to apt-get. It should probably be deleted now.
- get Felipa-Regular from github instead of (dying) googlecode - Also remove outdated comment
@jenshnielsen Thoughts? I suspect that the latex related failures were due to processes stepping on each other's toes. It is not clear that this is actually an improvement for us. @meatbalhat, should we be seeing speed ups? Is this the direction travis wants us to be moving in any case? |
@tacaswell The container-based infrastructure has much better resource guarantees than the legacy OpenVZ infrastructure, but it's a much younger offering that's undoubtedly going to require more rounds of tuning. The one area where we've gotten reports of degraded performance is with high file IO test suites such as pip. This is because the container-based setup does not currently have a tmpfs mount at As for processes stepping on each other's toes, is this the issue discussed above such as with Thank you! 🤘 😻 |
@meatballhat Yes, exactly those. I don't know how you deal with logging re-started tests, but we were getting more-or-less random errors of that form. Manually restarting the failing test would generally result in a pass. There still some un-restarted examples of this on the matplotlib repo on my personal (tacaswell) account. It looks like scaling the number of concurrent processes back to 2 (which iirc is the number of cores available, but I could not find the link last time I looked) seems to have fixed the problem with out degrading the run time. We are probably very high IO as we write out a lot of test images and the read them back in along with a baseline image and compare them, however I don't think we are currently using /tmp as the files get written back in to a folder the source directory (but we could fix that pretty easily and would probably be a big gain going forward once that is set up). Please let us know if there is anything else useful we can do from our end, travis is an awesome service 😄 🍻 . |
@tacaswell 2 cores is correct. I'm planning to address the tmpfs situation within the next week, which will hopefully have a decent impact 😃. |
@tacaswell It seems likely that we have some kind of race condition. If we can cut down to 2 process without performance degradation that sounds like a sensible solution. I guess we still have some kind of race condition causing the (relatively rare) random failures in font tests. I still think there is an issue with nose running multiple processes on the mac that I have been meaning to investigate for some time. This prevents me from having any chance of replicating the race condition locally. I also want to investigate parallelising the docs build with the new feature in Sphinx 1.3 but that might require changes to some of the Sphinx plugins. |
@tacaswell Do we want to merge this as is? Even if we don't see any performance improvement at this stage the wait time on the container based solution should still be shorter. |
I am in favor of merging this as-is. It does no harm compute time wise, should reduce variation in run time and I bet it will get rid of the random 'no speed up' test failures. It also seems to be what the travis folks want us to do and I am in favor of staying on their good side. At some point we should look into putting the saved images into tmpfs rather than a real disk which might get some performance back. |
Great I will wait a short while to see if there are any objections and then merge if not |
TST : first pass updating to use travis containers
This will not work currently, waiting on travis to whitelist needed
packages.
This is waiting on
travis-ci/travis-ci#3711 travis-ci/travis-ci#3710 travis-ci/travis-ci#3709 travis-ci/travis-ci#3708 travis-ci/travis-ci#3707