-
Notifications
You must be signed in to change notification settings - Fork 17
Instrument tests with custom macro & export over OTLP #2404
Conversation
b3ab9ea
to
de7d4c5
Compare
Should I squash Disable instrumentation by default for CI into the first commit? |
I'm happy for it to be in a separate commit! if anything, I'd slightly adjust the commit message to say "Disable test instrumentation by default on CI" |
Cool, I will make sure to rename it when I rebase! Another thing: it seems like the ARM build fails here due to use of gRPC-sys. I did try tonic, but it didn't actually work, so if we can get gprc working that'd be fantastic. The error is:
Maybe g++ needs to be added to the path for the ARM run? I am not entirely familiar with this CI setup, though, so I'm not sure how to go about this |
I'll have a look into this! |
Try rebasing on this: #2410 I just added C++ compiler; if it's installed, cmake should be enough to make it work. |
Thanks! I'll take a look in a sec. This is a dev dependency so hopefully it wouldn't affect deployment on raspiblitz. |
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.
We might have the opportunity to make this crate more usable for other crates in the workspace if needed (we wanted to use this in xtra-libp2p recently already)
bc3e022
to
9bdabca
Compare
I've rebased on top of #2410 |
oh wow, we fixed the previous error, but there still seems to be some onerous error when cross-compiling to ARM. |
Tonic had panics and dropped spans last I checked, so I think so, unfortunately. How important is instrumentation in ARM? If not so important, and the tests are just for CI, maybe the dep could be disabled? I'm not sure how this would work in a convenient fashion, though. |
seems like it was already installed :)
|
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.
Looks like a very convenient macro! Thanks for adding this.
otel-tests/src/lib.rs
Outdated
pub use futures; | ||
pub use opentelemetry; | ||
pub use otel_tests_macro::otel_test; | ||
pub use tokio; |
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.
❓ Might it be preferable to move these re-exported dependencies to the otel-tests-macro
crate instead of re-exporting them? From the perspective of any crate that depends on otel-tests
it doesn't make sense that it should re-export anything other than the otel_test
macro.
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.
IIRC depending on a crate transitively doesn't bring it into scope?
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's definitely not a big deal. But I think what I'm expecting is rust-analyzer
to, for example, offer me an otel-tests::futures::Future
import when I try to auto-import Future
. Just a minor annoyance if I'm understanding how this works.
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.
That's true. On the other hand, I don't want to force transitive dependencies to declare a whole lot of extra hidden dependencies.
Will RA still show up for #[doc(hidden)]
stuff? Maybe we could just #[doc(hidden)]
all of them...
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.
Haha, apparently we can hide re-exports that way because of this bug: rust-lang/rust#59368.
But would that also break the macro?
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 think this just affects rustdoc, but I think RA might ignore doc hidden stuff too
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 does say
Both of the re-exports above work just fine
in the issue I linked. I should read what I link to lol.
but I think RA might ignore doc hidden stuff too
Interesting! Can't hurt to try.
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.
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.
The current compile error is from |
we can give this a shot, from the perspective of opentelemetry it shouldn't make a difference. Feel free to give it a shot, because it would be nice to have this dependency! (and it would be good to keep running daemon-tests on arm, as it's one of our target platforms (main one as for now!) |
interesting, as the CI job wouldn't pass before we added that commit 😳 maybe it cached it after first run or updated paths? no se. |
sorry, I was not clear: the library is already installed on raspiblitz |
Success in CI on ARM!! Woo! |
Last issue is just around the IDE experience of re-exporting stuff. I'm not sure if this can be helped, though |
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!
(commit history needs to be cleaned up a bit to satisfy the CI)
otel-tests/src/lib.rs
Outdated
@@ -46,7 +52,7 @@ pub fn init_tracing() { | |||
// apply warning level globally | |||
.add_directive(LevelFilter::WARN.into()) | |||
// log traces from test itself | |||
.add_directive("happy_path=debug".parse().unwrap()) | |||
.add_directive(dbg!(format!("{module}=debug")).parse().unwrap()) |
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 guess you only used dbg!
for debugging :) (clippy would complain anyway before merging)
.add_directive(dbg!(format!("{module}=debug")).parse().unwrap()) | |
.add_directive(format!("{module}=debug").parse().unwrap()) |
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.
Good point! I missed this
otel-tests/src/lib.rs
Outdated
pub use futures; | ||
pub use opentelemetry; | ||
pub use otel_tests_macro::otel_test; | ||
pub use tokio; |
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's a net positive change even with that small awkwardness. IMHO as long as it doesn't come up first, and happens only in tests, it's not too bad. |
grpcio-sys does not compile on ARM otherwise.
68d8245
to
b3b8464
Compare
I've squished this down into two commits - one adding g++ to CI, and one adding instrumentation. |
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.
Thanks!
|
b3b8464
to
f36c3ed
Compare
bors r+ |
This PR uses a custom
#[otel_test]
macro to instrumentdaemon-tests
and export the spans over OTLP to Jaeger, when theITCHYSATS_TEST_INSTRUMENTATION
environment variable is set to1
.This currently uses the simple exporter. I tried the batch exporter, but this strangely caused some tests to hang.
TODOs