Crazy idea: I don't know whether this is in-scope for your project, or whether I should build it myself, but yours feels like the most similar project to what I'm imagining, so I thought I'd ask anyway.
At work, we have a bunch of complicated scripts in our package.json, and they depend on each other in nontrivial ways. Running yarn build will spawn a handful of codegen tasks in a carefully orchestrated manner, with a bunch of parallel tasks specified manually using the concurrently js package. It's like make but strictly worse. I want to rip it out and replace it with something that has an explicit concept of dependencies, and can avoid duplicated work. I've been putting off wrapping my head around the problem because I don't have a good way to visualise it at the moment.
I recently discovered (via https://stackoverflow.com/a/58188828) that if you run yarn config set script-shell $PATH_TO_WRAPPER_SCRIPT then you can change which shell runs your scripts.
I was thinking that I could make a tiny go/rust/typescript/bash program that:
reads the arguments (normally yarn will call it as sh -c "$BODY_OF_SCRIPT")
starts a span
named "$BODY_OF_SCRIPT"
as a child of any existing span that it finds in its environment variables
exports the span id into an environment variable so that it can be found by child processes
spawns sh -c "$BODY_OF_SCRIPT"
waits on the shell process to complete
reports the span to the otel collector over http
exits with the same exit code as sh
If I had this then I would be able to visualise the existing build process, and the whole thing would be a bit less scary.
a) Does the opentelemetry-shell project support linking parent/child relationships between shortlived child shells using environment variables?
b) If I built my idea using opentelemetry-shell, would you be interested in accepting it as an example in this repo?
extra context for if I decide to write it from scratch
My company is currently using datadog, and getting that set up locally was reasonably straightforward. I've not tried piping arbitrary opentelemetry nonsense into it, but it probably wouldn't be that hard. In the worst case I guess I could run zipkin in a docker container or something as a one-off. If I was building it from scratch, I would probably hack it together in a datadog-specific way, even though a standard otel-based implementation would be more useful to more people.
Thinking about it, having a README that says `docker run $PORT_FORWARDING_OR_WHATEVER zipkin` in one tab and `yarn config set script-shell /path/to/shelemetry && yarn build && yarn config delete script-shell && open https://localhost:$ZIPKIN_GUI_PORT/` then it will be easy for people to get started with it with no additional setup or dependencies.
Crazy idea: I don't know whether this is in-scope for your project, or whether I should build it myself, but yours feels like the most similar project to what I'm imagining, so I thought I'd ask anyway.
At work, we have a bunch of complicated scripts in our package.json, and they depend on each other in nontrivial ways. Running
yarn buildwill spawn a handful of codegen tasks in a carefully orchestrated manner, with a bunch of parallel tasks specified manually using theconcurrentlyjs package. It's likemakebut strictly worse. I want to rip it out and replace it with something that has an explicit concept of dependencies, and can avoid duplicated work. I've been putting off wrapping my head around the problem because I don't have a good way to visualise it at the moment.I recently discovered (via https://stackoverflow.com/a/58188828) that if you run
yarn config set script-shell $PATH_TO_WRAPPER_SCRIPTthen you can change which shell runs your scripts.I was thinking that I could make a tiny go/rust/typescript/bash program that:
sh -c "$BODY_OF_SCRIPT")sh -c "$BODY_OF_SCRIPT"shIf I had this then I would be able to visualise the existing build process, and the whole thing would be a bit less scary.
a) Does the opentelemetry-shell project support linking parent/child relationships between shortlived child shells using environment variables? b) If I built my idea using opentelemetry-shell, would you be interested in accepting it as an example in this repo?
extra context for if I decide to write it from scratch
My company is currently using datadog, and getting that set up locally was reasonably straightforward. I've not tried piping arbitrary opentelemetry nonsense into it, but it probably wouldn't be that hard. In the worst case I guess I could run zipkin in a docker container or something as a one-off. If I was building it from scratch, I would probably hack it together in a datadog-specific way, even though a standard otel-based implementation would be more useful to more people. Thinking about it, having a README that says `docker run $PORT_FORWARDING_OR_WHATEVER zipkin` in one tab and `yarn config set script-shell /path/to/shelemetry && yarn build && yarn config delete script-shell && open https://localhost:$ZIPKIN_GUI_PORT/` then it will be easy for people to get started with it with no additional setup or dependencies.