Run into a limit on the number of modules that dependabot can handle #19410
Comments
dmitryax
added
bug
|
Bringing it back to 220 didn't help — still the same error. Probably the limit was updated recently, and we run into it after updating |
|
I'll take a look at renovate next week, to see if it would be a good replacement. It may help with some of the other toil we have in the repo. It's also already in use in the opentelemetry-js repository. |
This moves updates for docker/docker-compose/github actions away from dependabot and over to renovatebot. Renovatebot will group PRs for those dependencies in a single pull request per dependency group. Related issue: #19410 --------- Signed-off-by: Alex Boten <aboten@lightstep.com> Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping |
codeboten
added
never stale
|
I think renovatebot can help us here. I've already started using it for docker/docker-compose/github action updates. I'm testing out ways we can use it for go packages as well. |
|
Has there been any update on this? I believe we have hit the updated limit of 220 now. Should the limit be bumped to 240? |
@MitchellGale this is not a limit we control, but rather a limit of Dependabot/Github. While we could modify the limit on our Makefile target it wouldn't help here |
dependabot.yml reached maximum limit so a package is getting dropped but CI will fail without this change. See open-telemetry#19410 Signed-off-by: Max Ksyunz <max.ksyunz@improving.com>
|
I propose that we overhaul how dependabot is used by adding a metadata entry that selects if the module should be considered for dependabot updates. For similar components, we can then just elect one to be the receiver of updates, and drop all other ones. This should allow us to stay under the 200 components. We can also set a score of dependabot for components from 1 to 5, and sort them by score and pick the first 200 components. |
**Description:** Change entirely how dependabot update entries are generated, by using the metadata.yaml status to find which components are most important in the distribution. The code now takes into account the distributions and the stability of the component as a score to decide whether to push the component. Go modules that don't have an associated metadata.yaml are not considered and therefore not present in the module updates path. **Link to tracking Issue:** #19410
…metry#27269) **Description:** Change entirely how dependabot update entries are generated, by using the metadata.yaml status to find which components are most important in the distribution. The code now takes into account the distributions and the stability of the component as a score to decide whether to push the component. Go modules that don't have an associated metadata.yaml are not considered and therefore not present in the module updates path. **Link to tracking Issue:** open-telemetry#19410
Fixes open-telemetry#19410 Signed-off-by: Alex Boten <aboten@lightstep.com>
Fixes #19410 --------- Signed-off-by: Alex Boten <aboten@lightstep.com>
.github/dependabot.yml validation fails with
https://github.com/open-telemetry/opentelemetry-collector-contrib/runs/11858014604
Any suggestions are welcome.
For now, I'm going to limit the number of update rules to unblock dependabot
The error says the limit is 200, but we hit it after updating it from 220 to 221
The text was updated successfully, but these errors were encountered: