Travis CI about amqp HOT 4 CLOSED

You could also try http://goci.me/

from amqp.

cheers @ftrvxmtrx, I'm pretty far with TravisCI support and @peterbourgon is working together with the Travis team to get a little more first-class Go support.

The unit tests are passing fine, but the integration tests (when AMQP_URL is in the environment during go test) are not completing in time. If http://goci.me had a RabbitMQ server within local range, I'd be welcome to try that as well. So far I can't narrow it down, nor get a stacktrace on timeout to see where the stall is actually happening. I suspect it's due to buggy shutdown, but would like to get a local or remote reproduction case to break into or stack dump.

http://travis-ci.org/#!/streadway/amqp for progress on the build.

from amqp.

re: Rabbit in Travis, it should work as-is with default credentials, so the timeouts indicate perhaps something else. I know I had to add basic sleep+retry logic to some unit tests of mine which depended on a server (which the unit test started) being present. Or maybe some error in "localhost" vs. "127.0.0.1" resolution? Maybe see these steps for how to explicitly set credentials. Also, note of warning:

we will have to disable most services on boot soon to save some memory, so
if you add a before_install line like this: sudo service rabbitmq-server start,
it should be future proof

edit: more suggestions: try enquotifying the AMQP_URL, and/or try adding this to the .travis.yml

before_script: sudo service rabbitmq-server status

second edit: actually, I'd bet it's that ConsumeBigBody test. It takes even a long time on my laptop, which is much more powerful than the Travis VMs.

from amqp.

Looks like the stall is related to a race condition in RabbitMQ where the consumer is getting handled after the publisher is finished. This should cause the test to fail and a wire dump will reveal if the messages are sent in the correct order and will likely require a small sleep between consumer setup and publishings.

The rest of the travis integration went very well now with native Go language support thanks to @peterbourgon and @michaelklishin.

from amqp.