You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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)
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.
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
The text was updated successfully, but these errors were encountered: