Merge lp://staging/~anybox/ocb-server/7.0-test-report into lp://staging/ocb-server

Hi Georges,

thanks, this is a great help in identifying failed tests! I'd love to have this available. However, the OCB-policy dictates that this patch would also be proposed to upstream OpenERP. Do you have such a proposal ready? To be able to quickly identify the status of this change in all projects, you should make a wishlist bug report that you link to both branches.

Hi Stefan,

thanks for kindly explaining policy ! I started indeed developing the change in OCB context (where it is useful now).

but I believe even in runbot, that could prove useful (don't know what's in current trunk, though)

Hi, Georges,

A useful proposal that we already use in all our buildbot slaves with success here at Acsone (thanks to buildout merge-in). I've also successfully applied the proposal on the official Openerp's trunk thanks to the merge-in functionality of buildout with:
merges = bzr lp:~anybox/ocb-server/7.0-test-report parts/openerp 5252..5253
Such a enhancement is now a requirement in our continuous integration methodology.

Thanks for the contrib.
lmi

Thanks for your work Georges.

On a technical side, it looks good! a bit hacky the way you find the path opening the __init__.py, but I guess you have to do that (and you're using the openerp tools). Perhaps it would be a bit cleaner to import the module you want and then take module.__file__, but that maybe doesn't even work.

On a functional side, I agree that is an improvement! I have something else to mumble that has nothing to do with your work: it doesn't feel very good to work to improve a custom bit of openerp that does a generic thing (in that case, a test runner).

In any case, lgtm!

Hello Georges,

this is an improvement rather than a fix. This is usually avoided on OCB (I encourage to explore ways of diminishing the cost of tracking branches and cherry picking). That being said, it's still a minor change with little side effects to expect. I would approve if you replay a MP to the official server as requested by Stefan and the OCB policy. Thanks for jumping into OCB, I think people should clearly understand the value of OCB.

#134 should be os.path.sep

Hi Holger, thanks for the review.

Yes you're right: I thought that tools.file_open did some normalization on '/' (similar to an URL) to do its magic lookup in the wanted addons directory, but after re-reading its code, I see it does not, and indeed expects the incoming ``name`` argument to be built with os.sep, as in:

    if name.replace(os.sep, '/').startswith('addons/'):
        subdir = 'addons'
        name2 = name[7:]

That's probably because it also accepts absolute paths.

btw, I don't know of any platform where os.sep is more than 1 char, but the above extract would be wrong on it.

Just pushed a new revision that addresses Holger's concern and Leonardo's remark by requesting the module's base path from openerp.module.module API.

misc.file_open does not proceed itself this way, but in case of discrepancy, I guess OpenERP would be in far more trouble than getting a yml test file path wrong in a test report... I checked quickly that it's consistent, though.

For the record, the branch against mainline openobject-addons has been updated, too

Leonardo: actually what --tests-enable (or oe initialize --tests) do is not so generic, since it does interleaving of modules initialisation and tests, so that each module's test suite is run with exactly the same demo data set no matter what dependent modules could later add.
Of course that's a consequence of the whole design of these tests. Other frameworks I used to work with solved the same kind of problems in other ways.

Rvalyi: thanks for the welcome ! You must have missed it, but right after Stefan's comment, I complied and created a bug, then linked the two branches to it.

Thanks!

Thanks for your explanation Georges.