nx-go VS otel-cli

Your go projects will share the go dependencies from the go.mod file in the root. Checkout https://github.com/nx-go/nx-go for getting started. Also, when generating a library you can follow the same approach as an app except you change it from app to lib.

As your applications grow in complexity, so do the tools required to build those applications. The Nx Build Framework and its accompanying product [Nx Cloud])(https://nx.app/) have made it easier than ever for JavaScript (and even non Javascript) developers to manage their build pipelines. Through its executors and tasks runners, Nx provides developers with an extensible monorepo to help developers manage dependencies between applications, create build scripts, cache results, and much more. When paired with Nx Cloud, these build artifacts can be cached in the cloud and distributed across build servers to speed up your CI Pipeline.

Not sure what they support these days but you might try https://github.com/equinix-labs/otel-cli or https://github.com/krzko/opentelemetry-shell

For the case of CLI apps, I'd recommend otel-cli to wrap CLI calls: https://github.com/equinix-labs/otel-cli

In this trace, we have taken the repository and built it in a distributed GitHub actions workflow using Nx Cloud’s distributed execution agents. The spans in this trace were generated across 5 different virtual machines. Using W3C Trace Propagation and the otel-cli, we were able to collect traces from all of these different machines into one trace. The @nxpansion/opentelemetry-tasks-runner can create spans under a parent span via the TRACEPARENT environment variable. Thus it is possible to create a root span for your workflow, pass that context to your agents executing the builds and create a single trace representing builds split across multiple machines.