open-telemetry / weaver

OTel Weaver lets you easily develop, validate, document, and deploy semantic conventions
Apache License 2.0
56 stars 19 forks source link

[FEATURE REQUEST] Ensure that weaver versions can be automatically updated through dependency managers #251

Open adrielp opened 4 months ago

adrielp commented 4 months ago

Is your feature request related to a problem? Please describe.

Part of the beauty of tools like the OpenTelemetry collector builder and mdatagen is that they are go binaries and can automatically be managed by go's native package manner. This is the tools.go pattern. Often, however, with tools called in workflows like through Make, dependency managed (Renovatebot/Dependabot) can't interpret those files as containing versioned packages. Often people default to writing custom regex's to do replacements, but it's not easy, practical, and prone to error (if it works).

Describe the solution you'd like

My feature request to essentially make this renovate-abotable in that for each repository using this package, they're able to get the benefits of renovatebot to auto update versions.

Additional context

This was discussed during the Semantic Convention Tooling SIG around the 21:00 minute mark

lquerel commented 4 months ago

I am not sure if this fully meets your request, but Renovatebot natively supports Rust and more specifically Cargo. Therefore, it is entirely feasible to let Renovatebot update a dependency to Weaver from any repository, whether it is a Go, Rust, C++, Java, or other type of repository. The main missing piece, I think, is to publish Weaver on crates.io. Another option would be to encapsulate Weaver in a Go program, but I am not certain of the benefits of doing so.

https://docs.renovatebot.com/modules/manager/

adrielp commented 4 months ago

I'm not super familiar with Rust (by familiar I mean I wrote hello world once years ago). The renovate-abot-ability (new words all the time) question was based out of common patterns I've seen when using container images like the below example where a makefile has the following:

WEAVER_VERSION=1.2.3
WEAVER_PACKAGE_URL=https://example.com/weaver

weaver-build:
  curl -L ${WEAVER_PACKAGE_URL/releases/${WEAVER_VERSION}
  ........
  # run weaver 

then dep managers won't know what type of package it is and how to update it (because Makefile isn't a package manager file).

tools.go works because it's a .go file that imports packages at versions through go.mod. Dep managers know that convention. Thus all make has to do is make install-tools which builds a binary out of package and version from go.mod locally for the CI to work.

I think what you're saying is that you'd recommend adding cargo install / run to repos that use weaver & have a Cargo.toml in each repo to signify version. Then make and other ci simply calls cargo to run that stuff? (correct me please)

bryannaegele commented 4 months ago

I think what you're saying is that you'd recommend adding cargo install / run to repos that use weaver & have a Cargo.toml in each repo to signify version.

That's probably the best approach when using make if you don't want to deal with the regex manager.