*** aclark has quit IRC | 00:05 | |
*** aclark has joined #zodb | 00:07 | |
*** aclark has quit IRC | 00:13 | |
*** aclark has joined #zodb | 00:50 | |
*** J1m has quit IRC | 00:52 | |
*** aclark has quit IRC | 01:32 | |
*** aclark has joined #zodb | 01:40 | |
*** aclark has quit IRC | 02:21 | |
*** jamadden has quit IRC | 08:09 | |
*** aclark has joined #zodb | 12:55 | |
*** jamadden has joined #zodb | 13:25 | |
*** aclark has quit IRC | 14:32 | |
*** J1m has joined #zodb | 16:08 | |
*** J1m has quit IRC | 19:16 | |
*** J1m has joined #zodb | 19:46 | |
*** jamadden has left #zodb | 19:54 | |
*** jamadden has joined #zodb | 20:31 | |
J1m | jamadden, I just enabled cocerals for zodb. Do I need to add any configuration to the project? | 20:46 |
---|---|---|
J1m | coveralls | 20:47 |
jamadden | yes, there needs to be a change to .travis.yml to upload to coveralls, and typically a .coveragerc config file added to do things like exclude tests. | 20:48 |
J1m | dang | 20:48 |
jamadden | does zope-testrunner have support for running coverage? I can't remember | 20:48 |
J1m | no idea | 20:49 |
jamadden | (oh, and when running under pypy, we want to disable coverage, it's *really* slow) | 20:49 |
J1m | I'm cribbing from relstorage | 20:49 |
jamadden | the key thing in .travis.yml is the `after-success: coveralls` block (and of course pip install coveralls in `install`). | 20:50 |
jamadden | You can just stick `coverage` as a command in front of some other python script and it usually just works, but its nicer if it's built into the testrunner, especially if the tests fork or use multiprocessing (I don't *think* zodb tests do?) | 20:51 |
J1m | jamadden, zope testrunner has coverage support, but there always seemed to be problems with it, so I never fooled with it. | 20:52 |
J1m | does the testrunner need to invoke coveralls? | 20:52 |
jamadden | A new block in .travis.yml does: `after-success: coveralls`, which will upload the .coverage file in the current directory IF everything passes | 20:53 |
J1m | I'd be surprised if running tests in multiple processes (-j) didn't screw up coverage. | 21:00 |
jamadden | There's an environment variable you set for that when running the tests, and a "cleanup" command you do after (`coverage combine`). I think zodbshootout does that. | 21:01 |
jamadden | but since .travis.yml doesn't use -j, it's not a problem | 21:02 |
J1m | It does for ZODB. Without it, the tests take longer to run and travis penalizes such tests. | 21:04 |
jamadden | I don't see -j in the .travis.yml (https://github.com/zopefoundation/ZODB/blob/master/.travis.yml#L23) | 21:04 |
jamadden | It got dropped in 2013 (https://github.com/zopefoundation/ZODB/commit/58b05544aa34a8ad30f5ac790e4295bb81e8b580) | 21:05 |
J1m | weird. But be why these tests get queued for so long. :) | 21:06 |
J1m | -j is crucial for ZEO tests. | 21:06 |
J1m | Must be... | 21:11 |
jamadden | which, argh, doesn't actually seem to run all its tests on Travis. ZEO's test_cache.py, fails on both Py 2 and Py3. Some tweaks let it run on Py2, but not on Py 3 | 21:11 |
J1m | what? | 21:12 |
jamadden | hmm. It works from the buildout but not from a virtualenv. | 21:13 |
jamadden | never mind, it's differences in the random numbers you get from random2 vs the native random on python 3…I guess I'll have to add that dep (I'm porting the cache stats tests to relstorage) | 21:16 |
J1m | are you cool with: https://github.com/zopefoundation/ZODB/pull/89 | 21:17 |
jamadden | I literally just made that comment :) | 21:17 |
J1m | :) | 21:18 |
J1m | The zope tests runner outputs a directory of overage data with a file for each source file. | 21:21 |
J1m | coveralls has no clue about that. :( | 21:22 |
J1m | the test runner also prints out a summary with a line for eaxh source file.... | 21:22 |
J1m | time to google... | 21:22 |
jamadden | `coverage combine` ? | 21:22 |
* J1m tries... | 21:23 | |
J1m | Holy crap. zope.testrunner has it's own coverage implementation based on trace | 21:29 |
jamadden | aww :( | 21:29 |
J1m | I give up for now. | 21:32 |
jamadden | thanks for looking at it. | 21:33 |
jamadden | The new checkUndoMultipleConflictResolution in pr 89 fails in RelStorage because RS explicitly doesn't support conflict-resolving undo, as it turns out | 21:47 |
J1m | we should probably start using unitests skip feature to deal with cases like this. | 21:50 |
J1m | or maybe factor those tests differently. | 21:50 |
J1m | This is a rather exotic feature. :) | 21:50 |
jamadden | I am going to skip it for now (I think we could support it with some work, but nobody has asked for it, according to the comment in RS). | 21:51 |
jamadden | but yeah, it would be nice if this test somehow magically didn't apply to RS in the first place :) (which is what I think you meant about factoring it differently…don't ask me how, though) | 21:51 |
J1m | those test could be factored into a separate test class that didn't get applied to RS. | 21:53 |
J1m | Or, we could add an interface to mark support for conflict-resolution in undo. | 21:53 |
J1m | and then use the skip mechanism. | 21:54 |
jamadden | in general, though, it's a tightrope walk between what new tests should apply and what should go in new classes that then manually have to be applied. | 21:54 |
jamadden | I like the interface idea | 21:54 |
J1m | But factoring the tests woykd be easier | 21:54 |
jamadden | skipping in RS is easy enough for now | 21:54 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!