|Travis support (again)||Florian Apolloner||2/25/13 2:48 PM|
so during the sprints a few people (thanks to everyone involved, sadly enough I can't remember all the names, so I refrain from mentioning an incomplete list) worked on adding and testing travis support to Django which resulted in this ticket: https://code.djangoproject.com/ticket/19891 and the PR: https://github.com/django/django/pull/805 -- The conclusion is that travis-ci seems to have improved quite a bit since I tested it (mainly it got more stable and they have more/faster machines now).
So all in all I think we could enable travis, but I have two questions:
* How much bash magic do we want in the .travis.yml file? One option would be to use a separate repo like I did in my initial work: https://github.com/apollo13/django/blob/travisci/.travis.yml (Personally I prefer my approach a bit more since it would keep the git history clean of changes which are only needed to configure travis properly if the baseimage changes etc...)
* Any objections to ship a file like the test_ci.py file in the PR (+ the accompaning docs, especially with regard to dj-database-url)?
|Re: Travis support (again)||Jacob Kaplan-Moss||3/7/13 9:38 AM|
On Mon, Feb 25, 2013 at 4:48 PM, Florian ApollonerI agree, +1 from me.
Yes, I like this. I'm constantly committing "fix travis" commits on my
other repos that use Travis, and that's annoying an crappy for a
project with a public timeline. So let's do something like a
"github.com/django/travis-support" repo and keep the .travis file
simple and clean.
I'd rather see this in the travis-support (or whatever) repo.
|Re: Travis support (again)||Chris Wilson||5/18/13 4:43 AM|
One issue standing in the way: Travis will try to build any branch without
a .travis.yml file as though it was a Ruby project. This will fail. It
may generate email notifications too, as they are enabled by default.
I think we need to add a .travis.yml file to *every* branch that we might
ever commit to (including packaging and stable/1.5.x) to tell Travis not
to build it.
Does anyone have a particular objection to adding this one file to old
branches, with minimal contents, e.g:
# see https://github.com/travis-ci/travis-ci/issues/902
I guess this would only cause problems if anyone's building an old branch,
or their own fork of django, in Travis. In which case they'll have to
resolve the merge conflict, and again whenever we change the .travis.yml
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
|Re: Travis support (again)||bo...@webatoom.nl||12/15/13 9:35 AM|
There's a policy change that landed a few weeks ago (27 nov) worth looking into:
Also django-cms/.travis.yml has a complete travis setup, including sqlite, postgres and mysql. Could be of inspiration for Django's travis config.
(reproduced from: https://code.djangoproject.com/ticket/19891#comment:32)
Op zaterdag 18 mei 2013 13:43:11 UTC+2 schreef Chris Wilson: