Fix for #19891 - Improved CI support for Travis, Jenkins and documentation #805

wants to merge 11 commits into


None yet
+ 'default': dj_database_url.config(env="DEFAULT_DB_URL"),
+ 'other': dj_database_url.config(env="OTHER_DB_URL", default="sqlite:///sqlite_other.db")

apollo13 Feb 24, 2013


Should be using an in memory db here for speed and to stay consistent with

+ # Run the test and be verbose about it
+ - ./tests/ --verbosity 1 --settings=test_ci

apollo13 Feb 24, 2013


Should run with -Wall to display warnings about unclosed sockets etc.


apollo13 commented Feb 24, 2013

I also think that we should restrict testing on travis to the master branch only. Pull-requests are supposed to be made against master anyways and jenkins runs the rest of the supported tests…

viciu and others added some commits Feb 24, 2013

Fixed #11295: If ModelAdmin.queryset returns a filtered QS don't requ…
…ire a 2nd count call

Original patch rewritten, added tests and get_filters_params method for ChangeList class.
Thanks Alex for the report.
Merge pull request #820 from viciu/11295
Fixed #11295: If ModelAdmin.queryset returns a filtered QS don't require a 2nd count call
Merge pull request #819 from erikr/master
Fixed #16302 -- Ensured contrib.comments is IPv6 capable.
Fixed #19253 -- Extracted template cache key building logic
Introduced a public function
Thanks @chrismedrela for fruitful cooperation.
Documentation on continuous integration.
How to use a CI servers while contributing to
Django. Related to #19891 - Travis support.

charettes commented Feb 26, 2013

Should we also test postgis, mysql_gis and spalitalite? I know postgis is doable but I don't know about the two others.


dokterbob commented Feb 26, 2013

Op 26-02-13 05:59, Simon Charette schreef:

Should we also test |postgis|, |mysql_gis| and |spalitalite|? I know
|postgis| is doable but I don't know about the two others.
Short answer: no, I don't think so (for now).

Long answer: GIS testing requires more scripting, i.e. for loading the
proper DB template in Postgres and for installing additional depedencies.

As having huge conditional scripts in a .travis.yml file constitutes
(huge) ugliness it would make a lot more sense to inlcude this in eventually, somehow, and allow this single command to take a
DB url and such.

But for this many (more) design decisions are required. As not to delay
Travis integration we chose to avoid them as much as we could for now.


dokterbob commented Sep 4, 2013

Related Travis issue travis-ci/travis-ci#1094


timgraham commented Sep 5, 2013

Closing for now since we're blocked on the Travis issue.

@timgraham timgraham closed this Sep 5, 2013


jezdez commented on 99edbe0 Dec 28, 2014

I don't understand why this wasn't put into django.utils.cache. Mind elaborating?


HonzaKral replied Dec 28, 2014

To me it made sense at the time because django.utils.cache only contains utils connected to request/response cycle where this seems unrelated. Also the existing module contains mostly internal APIs whereas this was meant explicitly for public consumption.

I can see the point you are raising though and don't feel strongly either way.

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