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

Put travis verification limits in documentation #1070

Closed
hamiltont opened this Issue Aug 28, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@hamiltont
Contributor

hamiltont commented Aug 28, 2014

As I've been setting up the vagrant stuff, I've noticed that multiple tests that pass in travis fail in a clean virtual machine running on EC2. This mostly seems ot be due to travis coming with a ton of pre-installed software, whereas the VM truly is clean. So we should encourage people to use the vagrant setup scripts and run inside a local virtual machine for full confidence in their code

@hamiltont

This comment has been minimized.

Show comment
Hide comment
@hamiltont

hamiltont Oct 25, 2014

Contributor

Tests requesting lots of RAM may not be able to allocate it consistently. Jobs are only guaranteed a small amount of RAM, and if the the worker is heavily loaded with jobs they may only get the min guarantee. If the worker is not heavily loaded they may get all the requested RAM. Only known fix at the moment is to check if os.environ["TRAVIS"] is set and start your system differently

Tests using multiprocessing.cpu_count will get inaccurate numbers on travis, where cpuset is used. Multiprocessing returns all CPUs on the machine, not CPUs your program is allowed to use.

Tests requesting lots of DB connections may not be able to get them all properly

Pool connect error: PostgreSQL FATAL 53300 remaining connection slots are reserved for non-replication superuser connection

Contributor

hamiltont commented Oct 25, 2014

Tests requesting lots of RAM may not be able to allocate it consistently. Jobs are only guaranteed a small amount of RAM, and if the the worker is heavily loaded with jobs they may only get the min guarantee. If the worker is not heavily loaded they may get all the requested RAM. Only known fix at the moment is to check if os.environ["TRAVIS"] is set and start your system differently

Tests using multiprocessing.cpu_count will get inaccurate numbers on travis, where cpuset is used. Multiprocessing returns all CPUs on the machine, not CPUs your program is allowed to use.

Tests requesting lots of DB connections may not be able to get them all properly

Pool connect error: PostgreSQL FATAL 53300 remaining connection slots are reserved for non-replication superuser connection

@hamiltont

This comment has been minimized.

Show comment
Hide comment
@hamiltont
Contributor

hamiltont commented Apr 3, 2015

@hamiltont hamiltont closed this Apr 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment