Enhance builder to capture go module for each component type

[djaglowski]

Resolves #10570

Alternative to #10598

This implementation is more reliable that #10598 because it gets information directly from the builder manifest. It relies on additional structure in the component.go file, ultimately encoded in otelcol.Factories.

An alternative would be to push the enhancements deeper, into the <kind>.Factories implementations, so that the module information is available directly alongside the Factory.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.27%. Comparing base (d37fe6c) to head (1ef5407).
Report is 22 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10599      +/-   ##
==========================================
- Coverage   92.34%   92.27%   -0.07%     
==========================================
  Files         395      397       +2     
  Lines       18669    18729      +60     
==========================================
+ Hits        17240    17283      +43     
- Misses       1069     1086      +17     
  Partials      360      360              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djaglowski]

Hmm, I thought I had tests passing. I'll move this back to draft status until I get CI resolved.

[evan-bradley]

Overall looks good to me.

[evan-bradley]

An alternative would be to push the enhancements deeper, into the <kind>.Factories implementations, so that the module information is available directly alongside the Factory.

I think the current placement is good for use in the components subcommand, but if we had a use for the modules at runtime, such as for observability, I could see that being a better approach.

[djaglowski]

I think the current placement is good for use in the components subcommand, but if we had a use for the modules at runtime, such as for observability, I could see that being a better approach.

I'm planning to investigate how to get the module info to the opamp extension, so likely will be looking into this more.

[evan-bradley]

I'm planning to investigate how to get the module info to the opamp extension, so likely will be looking into this more.

If we're comfortable relying on the output of this command, we could use it in the Supervisor to relay it to the OpAMP server. That would still be outside OpAMP extension, but at a minimum this will work for the current upstream Collector+OpAMP design.