travis hanging?

37 views
Skip to first unread message

Ralf Stephan

unread,
Feb 12, 2016, 11:41:10 AM2/12/16
to sympy
It appears that since yesterday no tests were completed. Illusion?

Regards,

Aaron Meurer

unread,
Feb 12, 2016, 12:03:36 PM2/12/16
to sy...@googlegroups.com
I believe it's running, but it's a bit backlogged. See https://travis-ci.org/sympy/sympy/pull_requests

It appears that each build takes about an hour to three hours to finish after the previous one. 

Unfortunately, since I merged https://github.com/sympy/sympy/pull/10084 (about a week ago), the Travis builds for SymPy are going to be a little slower than they were (which was already slow), because there are now more builds in the matrix. As soon as I create the release branch (I'm basically just blocking on this one issue https://github.com/sympy/sympy/issues/10082), I will create a new pull request against master which removes support for Python 2.6 and 3.2 (https://github.com/sympy/sympy/issues/10463), which should speed up the test times a bit (it will remove 10 builds from the matrix).  If necessary we can also stop running the allow_failure builds (builds which currently fail due to bugs in Travis or other issues outside of SymPy). 

Two other suggestions of things to help:

- Cancel builds for which there are already newer commits on the same branch. 

- If you are just waiting on builds because you want to see what tests failed (rather than waiting so that a PR can be merged), you can enable Travis on your fork of SymPy. Travis will then run the tests on your branches independently in their own queue, and you'll be able to see if they pass or not much quicker (but you have to check them yourself; the links on the PRs will still just reference the sympy/sympy Travis builds). Of course, you can also run the tests locally (./bin/test and ./bin/doctest).

Aaron Meurer


On Fri, Feb 12, 2016 at 11:41 AM, Ralf Stephan <gtr...@gmail.com> wrote:
It appears that since yesterday no tests were completed. Illusion?

Regards,

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/25f57592-8278-49ad-88d2-a3cc79ac0d46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ondřej Čertík

unread,
Feb 12, 2016, 12:25:09 PM2/12/16
to sympy
We really have to trim our tests, not just removing support for Python
2.6, and 3.2, but also sort all the tests for, say, Python 3.4 by
time, and remove N of the slowest tests. We should choose N so that
the overall test run is substantially reduced.

Then we should rework the slow tests, or test them separately, or
something, on a case by case basis.

Ondrej
Reply all
Reply to author
Forward
0 new messages