On 30 loka, 14:54, Florian Apolloner wrote:
> +1, debugging is just hard on travis (although I assume I could download
> their vm and test locally, but usually local stuff works :( ). We could
> choose a lightweight route and just enable travis for sqlite to get pull
> requests tested [Which would
Hi,
On Monday, October 29, 2012 1:29:14 PM UTC+1, Aymeric Augustin wrote:
>
> We tried moving Django's CI to Travis about 6 months ago. Unfortunately,
> Travis' time limit is too low for Django's test suite. We contacted them,
> but as of August 6th, we were still waiting for them to increase th
We tried moving Django's CI to Travis about 6 months ago. Unfortunately,
Travis' time limit is too low for Django's test suite. We contacted them,
but as of August 6th, we were still waiting for them to increase the limit.
I haven't had any news since then.
Over the last months I've had mixed feed
Hi all,
I can really recommend travis. We use it for testing Django REST Framework.
The config can be as simple as
this
https://github.com/tomchristie/django-rest-framework/blob/restframework2/.travis.yml
The availability of the travis service is not 100 %, this is mainly due to
the very lar
Travis or Jenkins can be setup to test PR's and use Github's API to mark the PR
as good to merge or not.
On Sunday, October 28, 2012 at 5:20 AM, Russell Keith-Magee wrote:
>
> On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger (mailto:dominicrod...@gmail.com)> wrote:
> > Another long time user h
Thanks for your feedbacks, they are really helpful.
I noticed existence of Jenkins test runner and also I found old
discussion about Django's testing infrastructure:
https://groups.google.com/d/topic/django-developers/_HfxwT7sVu0/discussion
What is the actual status of automated testing infrastru
On Sun, Oct 28, 2012 at 3:55 PM, Dominic Rodger wrote:
> Another long time user here (at some point I'd love to make the jump to
> contributor, just need to find more time) - out of interest, is there a
> reason we don't use Travis? I wonder if that might help those with commit
> access, since pre
Another long time user here (at some point I'd love to make the jump to
contributor, just need to find more time) - out of interest, is there a
reason we don't use Travis? I wonder if that might help those with commit
access, since pre-tested pull requests would mean you could have confidence
t
Hi Jan.
How I doing it. Until I work with patch I run only part of tests.(If I make
test at "modeltests/serializers/tests.py "
I run only "./runtests.py --settings=test_sqlite serializers" for fast
checking).
And before to submit patch on Trac I always run all tests. That allows to
working fast
Thanks Jan for the contributions.
I'll add a couple bits to Russ's excellent reply.
I generally will run just a specific test, or a subset of the tests while
developing the patch initially, this is much faster and can let you iterate
much more quickly.
Julien has put together a great tool for
On Sun, Oct 28, 2012 at 7:33 AM, Jan Bednařík wrote:
> Hi all,
>
> I'm using Django for more than four years and last week I started
> contributing.
>
> In docs about contributing I didn't find how detailed should be my testing
> while I'm writing or reviewing patch? Is enough to run tests only fo
Hi all,
I'm using Django for more than four years and last week I started
contributing.
In docs about contributing I didn't find how detailed should be my testing
while I'm writing or reviewing patch? Is enough to run tests only for
patched module? Or should I run full test suite for each patc
12 matches
Mail list logo
