Travis support (again)

[Florian Apolloner]

Hi,

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)?

Thx,
Florian

[Jacob Kaplan-Moss]

On Mon, Feb 25, 2013 at 4:48 PM, Florian Apolloner
<f.apo...@gmail.com> wrote:
> So all in all I think we could enable travis,

I agree, +1 from me.

> 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...)

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.

> * 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)?

I'd rather see this in the travis-support (or whatever) repo.

Jacob

[Chris Wilson]

Hi all,

On Thu, 7 Mar 2013, Jacob Kaplan-Moss wrote:

> On Mon, Feb 25, 2013 at 4:48 PM, Florian Apolloner
> <f.apo...@gmail.com> wrote:
>> So all in all I think we could enable travis,
>
> I agree, +1 from me.

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.
<https://github.com/travis-ci/travis-ci/issues/902>
<https://github.com/travis-ci/travis-ci/issues/414>
<https://github.com/travis-ci/travis-ci/issues/1095>

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
branches:
only:
- master
- travisci

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
file.

Cheers, Chris.
--
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.

[bo...@webatoom.nl]

There's a policy change that landed a few weeks ago (27 nov) worth looking into:

The new policy will be as follows:

1. If the commit occurs on the default branch, then the owners of the repository will be notified.
2. If the commit occurs on a non-default branch, the author and the committer of the commit who are also owners of the repository will be notified.

​http://about.travis-ci.org/blog/2013-11-19-upcoming-email-notification-policy-change/

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: