On Sun, Oct 18, 2009 at 6:14 PM, berto <roberto.c.agui...@gmail.com> wrote: > > On Oct 17, 5:33 pm, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> I'd like to fix this problem, but while this problem exists, adding a >> continuous integration server that crashes every time the developer >> makes a Syntax Error doesn't sound like an especially good idea. > > That's an excellent point. My initial implementation did have the > same problem, but I have since fixed it as well as runserver. The > changes are posted on github: > > - autoreload patch adds checking for modifications on files in an > errored state > http://github.com/rca/django/commit/ef96339f7e766700e8739a591b226b63b91cdcf7 > > - runserver patch adds files that have errors to the autoreload code > changed loop > http://github.com/rca/django/commit/e1d0be02b001155a09b012f4867de1efd14454b4 > > - updated version of runtester using the functionality above: > http://github.com/rca/django/commit/043e9723ae8fdb98745c2390f3ff92649bc106df > - and a minor patch to it: > > http://github.com/rca/django/commit/c1d62dbb58b1113a864ed5b1d35dd0b60ec2c071
That's great - but if you leave it on github, it's going to get forgotten. This issue is being tracked on ticket #9589. If you want to ensure this contribution isn't forgotten, turn your github changeset into a patch, and upload that patch to the ticket. You can also reference the github changeset in the ticket comments, but not all the Django core uses git. > But, just like the test command, the runtester command takes a list of > apps, or even a TestCase class within an app. That way you are simply > running a subset of the tests on the app actively being worked on. > For example: > > ./manage.py runtester some_app.SubTest > > With the above command, only the SubTest tests are run, which will > drastically reduce the time to run the tests. Granted time to setup > and teardown of the test environment is still there. Well, sure, except for the fact that if you do this, you no longer have continuous integration :-) The point of a test suite is that you run *all* the tests, so that you can catch *all* the possible regressions. Sure - if you're just doing a quick check of something, you might just run a single test, but you need to run the full suite to be sure. That's why I suggest that CI is better suited as a checkin trigger. A checkin is an indication that you think a body of work is complete. Running the full test suite is then an appropriate validation step. A single file save doesn't give you that sort of certainty that a body of work is complete. When it takes a while for a test suite to run (which will be true in Django even if you're only running a small subset of the overall suite), it could be easy for a test suite to start running on a partially saved set of updates, which could result in confusion over exactly which version of a which files were used to run a test. kGiven the fact that it takes a long time to setup and teardown Django's test suite, I feel that it is better to leave test execution as a manually invoked process. That way the developer can be certain of the exact file versions that will be used for a test run. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
