Moved the timeout documentation to the correct location, and added it to the help string. Also forgot to check for the no timeout case.
Should subsequent lines of the help string be indented?
Differential D6669
Documentation for test timeout chaoren on Dec 15 2014, 4:18 PM. Authored by
Details Moved the timeout documentation to the correct location, and added it to the help string. Also forgot to check for the no timeout case. Should subsequent lines of the help string be indented?
Diff Detail Event TimelineComment Actions Looks ok to me, but in the (hopefully near) future I would like to see LLDB_TEST_TIMEOUT change from an environment variable to an argument to dotest.py. Correct use of environment variables requires having intimate knowledge of the code in order to use correctly, increasing the code complexity. Having the value be a command line option means it's documented clearly for anyone just by running dotest.py --help Comment Actions Can dosep supply different arguments to different invocations of dotest? Comment Actions Isn't that the case with environment variable as well? Otherwise you would Comment Actions This is how I handle it: +Override the time limit for individual tests with LLDB_[TEST NAME]_TIMEOUT. Comment Actions That could still be solved with command line argument. For example: --default-timeout=5m --test-timeout={'TestConcurrentEvents': '2m'} Where the second one is a dictionary that can be directly parsed by python. I have to wonder though, is the ability to override test timeout worth the So i vote for one global timeout, and if it has to be overridable then an Thoughts? Comment Actions Although we could solve this with some of the suggestions above, I'm not sure it's that important as long as the global timeout is long enough to accommodate all of the tests and short enough that the wait is reasonable if there's a stuck test. 5 minutes seems like it would accomplish that. Comment Actions My concern, and the reason I brought it up, is because it seems like If this is just for making your own local test suite terminate in a And in addition to both of those, we really should be either fixing the Anyway, this patch is going in (or has gone in) for now, but I really don't Comment Actions
tests or disabling them. Now that this timeout is in, i have a feeling that Currently there are tests that only hang on the debian buildbot. These Remember, without the timeout feature, if a single test hangs, you need to Comment Actions Just to be clear, im totally on board with the global timeout. It's the |
You haven't said anything about setting env vars.