-
Notifications
You must be signed in to change notification settings - Fork 14k
Add a timeout to the remote-test-client connection
#147952
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
1d1f5fd to
799df1c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but I no longer have r+ permissions
| total_dur += dur; | ||
| } | ||
|
|
||
| panic!("Test device at {device_address} timed out"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be comforting with a test for this. I'm thinking a test where we make the binary connect to non-existing address and use a small timeout and assert on that it panics.
This comment has been minimized.
This comment has been minimized.
|
I'll assign myself to this one for now. r? Enselic |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found some more things. To avoid confusion for the test later: I would prefer a test that actually invokes the binary rather than having some kind of unit test.
b79af79 to
7a6c157
Compare
|
I'm currently happy with the way the code looks. So just a test left as far as I'm concerned. |
|
@Enselic Do you want me to factor out the main function so I can write a unit test for it or do you want me to write a test that actually runs the binary? If you want the latter, I don't know how to do it so I'd need some instructions. |
|
A test that actually runs the binary. I can see that we've had Another thing: We need to document the new environment variable in src/doc/rustc-dev-guide/src/tests/running.md. |
|
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
|
The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes. |
|
Can you split out the support for testing of remote-test-client in its own PR please? It will probably require some iteration as well. Then once that lands we can rebase this PR on top. @rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
|
@Enselic is it necessary to land it as a separate PR? it seems quite tied to the changes in this one, it would suck to land a separate PR only to find out that the tests here needed further changes to the test infrastructure. in general I feel like this PR is being held to a higher standard than most changes to remote-test-client. my understanding is that it didn't have a test suite at all before this change? it seems like a strict improvement to have an ok test suite and a ok tests rather than no tests at all. |
|
Well, reviewer guidelines say that stuff should be tested. And that PRs should be as small as possible. That is also an approach I personally think is preferred. So for me it seems natural to split. But I am completely fine with others doing r+ on this if they are happy with the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with landing these together given it's not too large.
It's a judgement call, would definitely also ask for a split if the test infra changes were larger. |
|
I edited the PR description to reflect that this PR is also registering a test step for @bors r=Enselic,jieyouxu rollup |
…-timeout, r=Enselic,jieyouxu Add a timeout to the `remote-test-client` connection Currently, the `remote-test-client` doesn't have a timeout when connecting to the `remote-test-server`. This means that running tests using it can hang indefinitely which causes issues when running tests on CI, for example. This PR now sets a default timeout of 5 minutes, meaning that if, for example, `TEST_DEVICE_ADDR=<IP:PORT> ./x test --target riscv64gc-unknown-linux-gnu tests/ui` is run and the `remote-test-server` is not reachable by the client, the client will panic after the timeout is reached. Additionally, the `TEST_DEVICE_CONNECT_TIMEOUT` env variable can be used to set up the timeout to any value (in seconds). This PR also wires up a test step for `remote-test-client`, which didn't previously have tool tests run in CI.
…-timeout, r=Enselic,jieyouxu Add a timeout to the `remote-test-client` connection Currently, the `remote-test-client` doesn't have a timeout when connecting to the `remote-test-server`. This means that running tests using it can hang indefinitely which causes issues when running tests on CI, for example. This PR now sets a default timeout of 5 minutes, meaning that if, for example, `TEST_DEVICE_ADDR=<IP:PORT> ./x test --target riscv64gc-unknown-linux-gnu tests/ui` is run and the `remote-test-server` is not reachable by the client, the client will panic after the timeout is reached. Additionally, the `TEST_DEVICE_CONNECT_TIMEOUT` env variable can be used to set up the timeout to any value (in seconds). This PR also wires up a test step for `remote-test-client`, which didn't previously have tool tests run in CI.
Rollup of 16 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147952 (Add a timeout to the `remote-test-client` connection) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
|
Since I was partly put as r on this I'd like to get rid of the two "Adress review comments" commits before merge (and it's not just me: that is also part of reviewer guidelines). This PR should be at most 2 commits. One to add test support and one to add the feature. I'm also fine with just one commit. @bors r- |
Rollup of 16 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147952 (Add a timeout to the `remote-test-client` connection) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
bd14144 to
08d3225
Compare
Currently, the
remote-test-clientdoesn't have a timeout when connecting to theremote-test-server. This means that running tests using it can hang indefinitely which causes issues when running tests on CI, for example.This PR now sets a default timeout of 5 minutes, meaning that if, for example,
TEST_DEVICE_ADDR=<IP:PORT> ./x test --target riscv64gc-unknown-linux-gnu tests/uiis run and theremote-test-serveris not reachable by the client, the client will panic after the timeout is reached.Additionally, the
TEST_DEVICE_CONNECT_TIMEOUTenv variable can be used to set up the timeout to any value (in seconds).This PR also wires up a test step for
remote-test-client, which didn't previously have tool tests run in CI.