Build info flag

[fld-opensource]

When using the stock collector, a custom build, it would nice to have something like a --build-info, it would output pretty version of the manifest (yaml config) used for the build. I would then be easy to see what receivers, exporters, processor etc ... we have built in.

[jpkrohling]

@esnible, this is similar to the PR you sent recently. Do you think this would have helped you debug problems with missing components?

[esnible]

@jpkrohling Yes, I believe it would be valuable to be able to find out what components are compiled in.
Doing this as a flag is OK. I'd rather ALWAYS see this information. Often I have the collector running on a pod I can't exec into, and I don't know what it offers. There isn't much of a downside towards always logging or printing this information.

It might also be good to include commit/version in the info output, perhaps using the technique of https://belief-driven-design.com/build-time-variables-in-go-51439b26ef9/ , for both opentelementry-collector and -contrib.

[jpkrohling]

We do have the commit/version already as part of the bootstrap logs and I agree it should definitely be part of the build info command.

[cuichenli]

i would like to work on this if it is ok.

[jpkrohling]

@bogdandrutu, @tigrannajaryan, is this something that would be accepted?

[bogdandrutu]

Happy to support this, but we need to look into:

1. Avoid having multiple ways of printing same thing, right now we already have "--version" flag.
2. Define what format to use (yaml, json, free text)?

[tigrannajaryan]

Related to #5438

[Chinwendu20]

Hi @cuichenli, are you still working on this? I will like to take this up

[cuichenli]

Hi @Chinwendu20 , no, I am not working on this.

[Chinwendu20]

Okay thanks, I would work on this. I just want to clarify that by a stock collector you mean, a custom built collector distribution. @fld-opensource

[tigrannajaryan]

Define what format to use (yaml, json, free text)?

I would definitely prefer this to be in a machine-readable format. Something like yaml is probably best since we can make it both reasonably human-readable and can also use for programmatic use-cases like this.

[Chinwendu20]

Hello @jpkrohling please could you point me to the bootstrap logs that you speak of? Does it mean that after the distribution is creation, there is a place the YAML config for generating it is stored?

We do have the commit/version already as part of the bootstrap logs and I agree it should definitely be part of the build info command.

[Chinwendu20]

Is this a correct visual representation of what the build-info flag should ouput?

[jpkrohling]

If you can generate a builder manifest like that, it would be great, but I don't think it's easily doable. It would already be useful to print out the list of components available, plus the version of the distribution. To get the version of the distribution, take a look at the output printed in the logs when starting the collector: there's already the build version there. When you find where this is printed, you'll find where the version information is stored.

[Chinwendu20]

Thanks for this @jpkrohling on it now