cfme.fixtures.rdb module¶
Rdb: Remote debugger
Given the following configuration in conf/rdb.yaml:
breakpoints:
- subject: Brief explanation of a problem
exceptions:
- cfme.exceptions.ImportableExampleException
- BuiltinException (e.g. ValueError)
recipients:
- user@example.com
Any time an exception listed in a breakpoint’s “exceptions” list is raised in rdb_catch()
context in the course of a test run, a remote debugger will be started on a random port, and the
users listed in “recipients” will be emailed instructions to access the remote debugger via telnet.
The exceptions will be imported, so their fully-qualified importable path is required. Exceptions without a module path are assumed to be builtins.
An Rdb instance can be used just like a Pdb
instance.
Additionally, a signal handler has been set up to allow for triggering Rdb during a test run. To
invoke it, kill -USR1
a test-running process and Rdb will start up. No emails are sent when
operating in this mode, so check the py.test console for the endpoint address.
By default, Rdb assumes that there is a working MTA available on localhost, but this can
be configured in conf['env']['smtp']['server']
.
Note
This is very insecure, and should be used as a last resort for debugging elusive failures.
-
class
cfme.fixtures.rdb.
Rdb
(prompt_msg='')[source]¶ Bases:
pdb.Pdb
Remote Debugger
When set_trace is called, it will open a socket on a random unprivileged port connected to a Pdb debugging session. This session can be accessed via telnet, and will end when “continue” is called in the Pdb session.
-
do_c
(arg)¶
-
do_cont
(arg)¶
-
set_trace
(*args, **kwargs)[source]¶ Start a pdb debugger available via telnet, and optionally email people the endpoint
The endpoint will always be seen in the py.test runner output.
Keyword Arguments: - recipients – A list where, if set, an email will be sent to email addresses in this list.
- subject – If set, an optional custom email subject
-