#DAG Visualizer
1 messages · Page 1 of 1 (latest)
Hi @proud thorn,
@weary rose managed to do a small POC around that: basically representing the DAG in .DOT. External observation of a dagger execution would currently be hard to implement. stdout would be possible with --log-level debug, which expresses the dependency. However, it would be hard I think
I don't know if the dag visualizer is out of scope but I'd say this would really help. debug log levels is quite noisy - we really need to dig up the stuff there.
To clarify, we would love DAG visualization and will build it eventually, it’s really just prioritization (more urgent things to do first)
Just a side note, you can currently get opentelemetry traces from your builds. While this does not visualize the DAG per se, it does help visualize the execution in a different way. Maybe that will be helpful in the meantime before we support something a bit more specialized and DAG-specific.
Instructions on configuring it are here: https://docs.dagger.io/1223/custom-buildkit/#opentelemetry-support
There is also some ongoing work that might enable you to get tracing out of the box by running Jaeger inside buildkit itself, but right now you have to setup Jaeger externally.
Using a custom buildkit daemon
I see. Thanks for the context. Personally, I think it's more of a nice-to-have, but it does make Dagger a harder sell if our existing solution (custom CI framework based on Argo Workflows on K8S) does visualize. So it currently comes down to a trade-off Dagger's ad-hoc extensibility and being able to run locally versus having better glance-ability when something fails in CI. Glad to hear that one day we might have it all 🙂
I imagine it's also non-trivial to figure out how to generically visualize the DAG so that it would be useful. It would need some filtering API, to hide away nodes that are just too low level.
@proud thorn question, would it be an easier sell, and perhaps a better fit for your use case, to use Dagger to automate certain actions within your custom CI workflow, rather than to replace the entire workflow?