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

[Request] Investigate alternatives to Dependabot #363

Open
andrewazores opened this issue Apr 11, 2024 · 0 comments
Open

[Request] Investigate alternatives to Dependabot #363

andrewazores opened this issue Apr 11, 2024 · 0 comments
Labels
build chore Refactor, rename, cleanup, etc.

Comments

@andrewazores
Copy link
Member

Describe the feature

Dependabot has been generally serving us well across our various components, however there are some annoyances:

  1. We try to keep our upstream dependencies aligned with what is available for downstream builds so that packaging and distribution is as simple as possible. This means we often have a delay between when an upstream dependency becomes available and when Dependabot notifies us, and when we actually want to merge the PR updating it. This leaves PRs open for a long time, which is unhelpful clutter and also produces a lot of rebase activity notification noise.
  2. Because the PRs are often left open so long, they are also often superseded by even newer upstream dependency versions. Dependabot closes the previous PR and opens a new one for the latest version. Now we must manually check our dependencies for downstream availability and find the latest version available, meaning Dependabot is no longer really bringing any value.
  3. Some of our dependencies, such as Quarkus, maintain multiple release branches. We prefer to stay on the LTS minor versions, but Dependabot doesn't know about this and always just suggests the latest and greatest release. It would be better to receive automated updates to patch versions only for dependencies like this.

https://github.com/renovatebot/renovate looks like a good option from some cursory reading. It seems to support various versioning schemes including semver, and allows version update ranges for individual dependencies so we can express a requirement like only updating patch versions. It also opens an issue that tracks dependency update availability and allows maintainers to select which ones should become PRs, so it will be less noisy. But there may also be other good options out there.

Anything other information?

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build chore Refactor, rename, cleanup, etc.
Projects
None yet
Development

No branches or pull requests

1 participant