-
Notifications
You must be signed in to change notification settings - Fork 2k
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
IDT init #29174
IDT init #29174
Conversation
PR #29174: Size comparison from 8d0761d to 49256ff Increases (2 builds for bl702, telink)
Decreases (1 build for efr32)
Full report (65 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
I don't want to block you on this, but without re-reviewing all of the code, I'm having a hard time remembering my mental class diagram. Just the feeling of the tool give me the feeling there should be a a set of Monitors with a few lifecycle methods like setup, start monitor, stop monitor, cleanup, and depending on how you want to structure it, a pull artifacts, or flush records, or potentially you setup the monitor feed to be streamed to a destination during the setup. I'm not sure where Discover fits in there. Just thinking about the Monitor(s), I would have a directory called /monitor/ and have a sub-directory for each implementation. Are you trying to "discover" think that could be Monitor'ed? Or are you just trying to start observing monitoring the network? |
Ah got it, thanks! I don't have a great alternative unfortunately.
I am not certain all of them will work if used individually and executed not sourced. Probably most will, but a couple things could be broken.
For book keeping: this is the current behavior, so we're good here.
Discovery is just meant to make life a little easier for a manual tester, nothing more. I think the general structure you're suggesting is aligned with whats here, however this is meant to be executed manually instead of a continuous process (not that that can't change in the future). |
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.
Awesome stuff!
PR #29174: Size comparison from 568362a to 31a2a7e Increases (1 build for telink)
Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
PR #29174: Size comparison from 87c16cf to f81a10a Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
* IDT init * Restyled by whitespace * Restyled by prettier-markdown * Restyled by shellharden * Restyled by shfmt * Restyled by isort * Remove f-strings with no placeholders * Remove unknown Pygments lexer * Spelling * License headers * Restyled by prettier-markdown * First response to PR comments * Restyled by prettier-markdown * Respond Dockerfile and README comments * ble nit, venv script * Make TXT logging better * Respond comments * Clarify single host installation * Respond comments * Respond nits * Cleanup BashRunner * Cleanup BashRunner usage * Respond comments, renames, opts * Nits * Restyled by prettier-markdown * Restyled by shellharden * Restyled by shfmt * Restyled by isort * Spelling * Dynamic loading, comments * README nit * Make README generic, add async, any interface * Restyled by prettier-markdown * Restyled by shellharden * Restyled by shfmt * Restyled by isort * Nits, workaround potential issue with shell input * Restyled by isort * Docs CI --------- Co-authored-by: Restyled.io <[email protected]>
IDT is a CLI tool used for capturing data and inspecting an environment during manual interoperability testing.
Please see
src/tools/interop/idt/README.md
included in this PR for all details of the tool.Although the tool is relatively early in development, we would like to encourage collaboration by including it here asap.