-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Improve dependency management #18925
Comments
Thanks for all your work experimenting and writing up the findings @ivanvc! I am in favor of moving away from needing to manually raise a pull request every week to bump dependencies to instead be able to merge automated pr's raised by renovate, so option 3. This will be less toil for the community to manage, and one less bespoke project specific process for new contributors to learn. |
Questions:
|
That's a good question. I think so, because they will be editing the same files. This may slow down the merging process of the whole week's dependencies. However, we can fine tune how often the bot opens the pull requests (i.e., you can specify how many per hour it should open).
Yes, and you just made me realize that because of how we do the dependency management, we may not ever be able to do a single pull request (if they ever support multiple commits in a single one), because we would want to remove some dependencies that are purely indirect, but we want to keep the ones that are direct in some submodules but indirect in others. |
One idea we could add all purely indirect dependencies to the renovate ignore list. Provided renovate would still bump them when a direct dependency requires it which I would think it would as it runs go mod tidy. |
OK. Since usually we just have several dependency bumping (i.e. around 3) each time, so it might be fine. Regarding the frequency, either Weekly or bi-weekly is OK to me.
It will introduce extra maintenance effort, because the list may change over time. |
It may need some experimentation, but maybe through commands we could cherry pick some dependencies out of the grouped PR, following James' idea. I'll report back. |
I opened a dependabot-core issue (dependabot/dependabot-core#11046) to track the lack of running Unfortunately, renovate doesn't have an interactive bot interface in the PR like dependabot. I was also testing dependabot trying to ignore a single dependency in a grouped PR, but it doesn't seem to work (ivanvc#447) |
What would you like to be added?
The current dependency management process involves a lot of manual intervention. There have been some attempts at improving it, including updating the
update_deps.sh
script, trying out different dependabot configurations, and evaluating other tools besides dependabot.I want to formalize the work and have a central place to discuss alternatives, pros, and cons.
Possible approaches
directories
property: The result of this is multiple pull requests for the same dependency across all of the submodules where it is present. Although we (@jmhbnz and I) thought this was going to be the silver bullet, in the end, it doesn't work as we expected. Enabling this will just add noise to our repository, as we still need to create a PR to bump dependencies manually. See the following example ofgo.opentelemetry.io/otel/trace
in my fork: build(deps): bump go.opentelemetry.io/otel/trace from 1.30.0 to 1.32.0 in /tests ivanvc/etcd#410 build(deps): bump go.opentelemetry.io/otel/trace from 1.30.0 to 1.32.0 in /server ivanvc/etcd#406 build(deps): bump go.opentelemetry.io/otel/trace from 1.30.0 to 1.32.0 in /etcdutl ivanvc/etcd#390 build(deps): bump go.opentelemetry.io/otel/trace from 1.30.0 to 1.32.0 ivanvc/etcd#386.directories
property andgroups
. Although this looked promising, as it creates a single pull request with all the weekly dependencies, the issues that I find are: 1. it creates a single commit for the whole group (rather than one per dependency bumped), 2. it doesn't rungo mod tidy
, and it breaks our CI. See an example in my fork: build(deps): bump the weekly-updates group across 12 directories with 70 updates ivanvc/etcd#265 (in the files changed and anygo.sum
file, it's clear that it is not tidying them).directories
beta feature moved to renovate. The immediate issue is that we would need a new GitHub application installed for our GitHub organization. This is not the silver bullet but may help decrease the effort. I tested some configurations in my fork:I lean towards 3i (renovate + one pull request per dependency), which would be one small step to improve the process. But I want to open the topic for discussion.
cc. @ArkaSaha30
Why is this needed?
To decrease the toil of keeping dependencies up to date.
The text was updated successfully, but these errors were encountered: