[ckan-dev] test failures

Fri Feb 4 11:20:47 UTC 2011

Ahh I see. OK, this isn't a good solution then. I don't have any 
suggestions other than writing a script to change those options as part 
of the buildbot before it is run. I can see accidental test.ini changes 
being made all the time otherwise. Any other ideas?

Cheers,

James

On 04/02/11 10:51, David Read wrote:
> On 4 February 2011 10:37, James Gardner <james at 3aims.com 
> <mailto:james at 3aims.com>> wrote:
>
>     What we actually agreed was that David would add a buildbot.ini
>     file *in addition* to the test.ini file. Then if anyone wanted to
>     run the tests exactly as buildbot does (ie with postgres) they
>     could run:
>
>         nosetests ckan/tests/ --config=builbot.ini
>
>
> But that's the nose config, not a pylons config.
>
> test.ini is referred to in the tests/__init__.py. I guess you're 
> thinking of 'nose --with-pylons=buildbot.ini', but then you have to 
> replicate all the rest of the test.ini options (apart from the 
> sqlalchemy one) in there. You also have to work out how to tell the 
> other pylons instances that tests start independently to use this 
> other config file. So I don't see it as simple as you suggested.
>
>     Unless there is a good reason not to do this, let's just do that
>     as agreed? I can't see the problem.
>
>     James
>
>
>
>
>     On 04/02/11 09:04, David Read wrote:
>>
>>
>>     On 3 February 2011 22:35, David Raznick <kindly at gmail.com
>>     <mailto:kindly at gmail.com>> wrote:
>>
>>
>>
>>         On Thu, Feb 3, 2011 at 9:50 PM, David Read
>>         <david.read at okfn.org <mailto:david.read at okfn.org>> wrote:
>>
>>             Hi all,
>>
>>             I've changed buildbot to run ckan tests twice now:
>>             firstly with sqlite and then again with postgres in the
>>             same buildbot script (I should split it into two tasks,
>>             but that is for another day). I've fixed a few problems
>>             with the tests under sqlite and they pass now, but there
>>             are still problems with tests in postgres.
>>
>>             Seb changed lots of 'rebuild_db' statements to
>>             'clean_db', which then requires 'init_db' at the start of
>>             the next test. So there are now 'init_db' statements at
>>             the start of a great many tests. Was there any reason for
>>             this?
>>
>>
>>         This may not be necessary any more with the fix we did the
>>         other day on migrate.  However, the in memory sqlite database
>>         gets lost mysteriously sometimes and its hard to figure out
>>         where.  That is why I thought the init_dbs were there.
>>
>>
>>     These problems are with postgres in this case, and there is no
>>     mystery about losing the d.b. - we call clean_db!
>>
>>     Note to Seb: Things were probably working in the past because the
>>     'faster_db_hacks' config option wasn't being read properly, which
>>     David and I fixed last Friday, so the full init_db was happening
>>     even with postgres, whereas it's not now. Also the init_db
>>     parameter 'conditional' (BTW what a terrible name for a
>>     parameter...!) is not being used. I think basically this all
>>     needs a bit of a review / tidy up to get it to make sense and
>>     work too.
>>
>>             It seems a right faff to remember this - is there no
>>             better way? Indeed I believe the current test failures
>>             are caused by a test not having a init_db.
>>
>>             Note for everyone: Seb, James and I have agreed to set in
>>             test.ini to use sqlite.
>>
>>
>>         I disagree to this.  You should specify what database you
>>         want in your own development.ini.  The template
>>         development.ini could have sqlite as the default instead. 
>>         This is the only sane way to do it in my opinion.
>>
>>
>>     Yes this might be better. Anyone else?
>>
>>             We think it is a good idea to default tests to being run
>>             quickly. However, I can't see a good way to then run
>>             tests under postgres - if you comment out the sqlite in
>>             test.ini (as the buildbot currently does), 9/10 times you
>>             end up checking it in by mistake. Maybe someone has a
>>             better idea, since passing parameters to nose is a no no.
>>
>>
>>         Why is this a no no?
>>
>>
>>     From what I read, nose doesn't believe in passing parameters onto
>>     tests - they should be stateless. You can fudge it by hacking
>>     argv, but then you lose flexibility of the many useful nose
>>     command-line params.
>>
>>     Dave
>>
>>
>>             David
>>
>>             _______________________________________________
>>             ckan-dev mailing list
>>             ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>>             http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>>
>>
>>         _______________________________________________
>>         ckan-dev mailing list
>>         ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>>         http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>>
>>
>>     _______________________________________________
>>     ckan-dev mailing list
>>     ckan-dev at lists.okfn.org  <mailto:ckan-dev at lists.okfn.org>
>>     http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
>     _______________________________________________
>     ckan-dev mailing list
>     ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>     http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110204/417f4f97/attachment-0001.html>