Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adrielp opened this issue Jul 18, 2024 · 3 comments

Comments

@adrielp
Copy link

adrielp commented Jul 18, 2024

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
Copy link
Contributor

lquerel commented Jul 18, 2024

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
Copy link
Author

adrielp commented Jul 18, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants