Build timeout on Travis CI when testing with lettuce + splinter and selenium

Question

I have about 130 lettuce tests which runs fine locally, but when travis runs them it hangs after a few tests.

Here the tests fails at the 8th scenario: https://travis-ci.org/h3/django-editlive/jobs/3945466

And when I remove the last scenario it passes: https://travis-ci.org/h3/django-editlive/builds/3945648

I tried splitting my tests in separate features files, same problem.

It's doesn't seem to be caused by a specific scenario, but rather by the number of scenario ran.

According to Travis' docs:

• Waiting for keyboard input or other kind of human interaction
• Concurrency issues (deadlocks, livelocks and so on)
• Installation of native extensions that take very long time to compile

The only possibility I could see is a concurrency issue .. but how can I debug it ?

My project is open source so the entire source code is available here:

• https://github.com/h3/django-editlive
• lettuce-features

Answer 1

I have no definitive answer about the problem, but I managed to work around it.

Since I had no output whatsoever I tried to strace my tests so I could see exactly where it hangs.

But the strace output was to big hand was trimmed by travis .. So I had to grep -v some lines.

Here's what it looks like in my .travis.yml file:

script:
  - "strace -q python project/manage.py harvest 2>&1 | grep -v ENOENT"

ENOENT Stands for "No such file or directory", I didn't really need it to make sense of strace output and it cutted enough line to let me see where it hanged.

Turns out it was hanging on a request to selenium:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(35146), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
send(4, "POST /hub/session/e7cba641-2842-"..., 359, 0) = 359

I couldn't really replace selenium, so I took a wild guess and replaced firefox with google chrome to run my test .. et voila. Tests ran perfectly.

It sucks that I haven't really solved the problem, but debugging remotely on travis ci is a PITA at best. And with a waiting time of 35min between each iterations I have more important things to do.