log.Origin: ensure to avoid parent loops (details)
Commit
daf96e449e48ab43fa452d49d3d2d9e7a14e2840
by Pau Espin Pedrol
test: Remove unused variable Failure Commit 6ccda11a98afd6f4459e9ff1c24de4ad4450de23 removed its use but forgot to remove it on this line. Change-Id: I90375ce1e4b8e0b7e140df908323bc269e0baf40
Commit
61b07213199e40f1fa1c52ec528b11d9ab4bdc47
by Neels Hofmeyr
junit result: also write for aborted runs Even if aborted due to signal, write a JUnit report XML, and make sure to indicate the runs as erratic. Change-Id: I7a334ef3463896c543c0fe592d3903c15e67d4c4
Commit
b068c6e911c11549d1d412d92955e8090e98d137
by Neels Hofmeyr
refactor logging: drop 'with', simplify Refactor logging to simplify use: drop the 'with Origin' style completely, and instead use the python stack to determine which objects are created by which, and which object to associate a log statement with. The new way: we rely on the convention that each class instance has a local 'self' referencing the object instance. If we need to find an origin as a new object's parent, or to associate a log message with, we traverse each stack frame, fetching the first local 'self' object that is a log.Origin class instance. We just call log() and it finds an Origin object to log for. When an exception happens, we first escalate the exception to where ever it is handled, and only then the log.log_exn() function finds an Origin object in the traceback's stack frames. Hence the 'with log.Origin' happens implicitly, no more hassles. Furthermore, any frame can place additional information in a local variable called log_ctx. This automatically inserted in the ancestry associated with a log statement. Change-Id: I5f9b53150f2bb6fa9d63ce27f0806f0ca6a45e90