nedbat
commented
7 years ago Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary)
Following the instructions and fixing the problems I found on the way, I ran this:
- docker run --privileged -p 8080:80 -t -i ubuntu:14.04
- apt-get update
- apt-get install software-properties-common curl git
- git clone https://dachary@bitbucket.org/reeteshranjan/coverage-testapp.git
- edited setup.sh to replace 2.2.6 with 2.2.8
- ./setup.sh
-
- accepted the oracle license
-
- typed coverage as the password when prompted
-
- it may be necessary to re-run setup.sh a few times because of timing issues with cassandra setup
- source /usr/local/bin/virtualenvwrapper.sh
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
- workon coverage
- coverage run --source="." manage.py runserver
- curl "http://127.0.0.1:8000/api/v1/testcov"
#!bash
Exception Type: ProgrammingError at /api/v1/testcov Exception Value: relation "core_buyer" does not exist LINE 1: INSERT INTO "core_buyer" ("id", "first_name", "last_name") V...
I did not try to fix this last error. My advice is that you provide and test detailed instructions to create a reproducer for this bug. The proposed reproducer is a good step forward but it fails in a number of ways and cannot be used effectively.
Originally reported by Reetesh Ranjan (Bitbucket: reeteshranjan, GitHub: reeteshranjan)
We have a django app that talks with 2 DBs - postgresql and cassandra. Though the django app's runserver starts up fine and work (with ./manage.py runserver) as well as we have a gunicorn+nginx setup that works fine, when I try to measure coverage using a command like this:
coverage run --source='.' manage.py runserverthings don't work as the django app bails out with connection failure with cassandra.
Nothing changes across running with coverage or running normally. Cassandra server has not stopped across these 2 ways of running the server. Is there some issue with authentication that cannot be taken care when running with coverage. All the auth is anyway in the django settings, and there is no hack or anything that goes beyond django structure.
Here is the trace of the failure:
And here is how it works fine without coverage:
System check identified no issues (0 silenced). November 12, 2015 - 10:52:50 Django version 1.8.3, using settings 'sweatt.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
I have installed the coverage tool today and I can see the version to be 4.0.2 as in /usr/local/bin/coverage, /usr/local/bin/coverage2 and /usr/local/bin/coverage-2.7.
I am using ubuntu 14.04 and python 2.7.