Enable Dependabot for etcd if we see a good fit

[vivekpatani]

What would you like to be added?

Dependabot

Should we introduce this tool?

Why is this needed?

Pros:

1. Notifies of newer library versions (https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates) - by notifications or creates an automated PR. This helps us is keeping up with the latest versions, which in some degree may bring in bug fixes/security updates/improvements/etc.
2. Notifies of insecure library versions (https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) - helps us with detecting if there are any security issues with any of our libraries.

Cons:

1. More noise from the bot (depends on how we configure it)
2. Can sometimes fix problems, which may be a good-first-issue for some folks trying to engage with the open source community.

Please feel free to feedback, this is just a suggestion. Thanks.

[serathius]

I'm all for it.

More noise from the bot (depends on how we configure it)

We just want to get a PR once a week that updates dependencies in go.mod. Doesn't seem like to much noise.

Can sometimes fix problems, which may be a good-first-issue for some folks trying to engage with the open source community.

Don't think pushing toil to new contributors is a good experience for them.

[vivekpatani]

@ahrtr @spzala @mitake @ptabor any thoughts?

[ahrtr]

I don't have strong opinion on this, but I think it's worth a try.

[vivekpatani]

@serathius would you or one of the maintainers enable this? Seems like I'm not authorised to do this.

[serathius]

@vivekpatani Dependabot is enabled by adding a configuration to repository. Anyone can create a PR that adds it. Only difference for maintainers is that they can do that directly on main branch, which doesn't make sense as it voids code review.

Feel free to send the PR that adds the configuration, you just need to add a .github/dependabot.yml file. Default contents that might need some adjustments

# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
  - package-ecosystem: "" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "weekly"

[vivekpatani]

@serathius thank you, I'm out for a week, will to get once back, if someone takes it up before, they are welcomed, else will attend to it once back.

[sanmai-NL]

Why Dependabot over Renovate?

[vivekpatani]

My only reason was first party integration. Just out of curiosity, for the problem we're trying to solve (and for the sake of extensibility), why Renovate over Dependabot? Thanks a ton for your feedback @sanmai-NL

[sanmai-NL]

Renovate has more features and more extensive platform compatibility. For example, should this product be migrated to GitLab, Renovate will still work (as in officially). Renovate also supports updating container images and smart grouped update strategies.

[sanmai-NL]

See https://blog.frankel.ch/renovate-alternative-dependabot/.

[vivekpatani]

@sanmai-NL makes sense.

@serathius @ahrtr do y'all have a preference? I'm open to both. FYI: Known Limitations

[ahrtr]

We have already enabled and configured dependabot for more than 1 month.

I agree Renovate supports more platforms and more generic, but github natively supports dependabot, and it can meet almost all the requirements so far.

The only problem on dependabot (I guess most likely Renovate will have similar issue) is it automatically creates a PR for each module for exactly the same dependency. Let's work with an example. Multiple modules (e.g. client/v3, etcdctl, etcdutl, pkg, server, test) depend on github.com/dustin/go-humanize, so dependabot automatically creates the following PRs,

• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /server #15120
• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /client/v3 #15119
• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /etcdutl #15117
• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /pkg #15114
• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /etcdctl #15113
• build(deps): bump github.com/dustin/go-humanize from 1.0.0 to 1.0.1 in /tests #15122

Obviously it doesn't make sense. It makes more sense to do all of them in one PR, So each time I need to spend about 10 ~ 20 minutes to do it manually. see ac98432#diff-f78c03795cb3f701a5a20c16aa553797113f267e781fe66033bcf35bc837919a

Usually when we bump any dependency, we also need to run "./scripts/fix.sh" to tidy up all the go.mod and go.sum files, but dependabot isn't smart enough to be configured to do it.

I do not see strong reason to replace dependabot with Renovate for now, because I only see effort, but no benefit, unless Renovate can resolve the above painpoint.

[serathius]

Totally agree on the pain point. Such automation should save time and not generate more toil. It's not great and we are only chugging along because @ahrtr cleans the PRs manually.

Would be great if someone could:

• Reduce the frequency of dependabot PRs
• Reduce number of duplicate PR
• Make it work with multi package projects.

Not sure if those can be addressed by configuring Dependabot or migrating to Renovate, but that would be only work that would benefit the project currently.

Thanks for all the work with dependencies @ahrtr!

[sanmai-NL]

@ahrtr Why do you assume Renovate has the same limitation? And then conclude there would be no benefit? This requires proper research.

Please see https://docs.renovatebot.com/noise-reduction/.

[serathius]

FYI #15313, should remove most of the spam.

[ahrtr]

dependabot/dependabot-core#6678

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[sanmai-NL]

Not stale.

[serathius]

@ahrtr @sanmai-NL is there anything left to do here? We have dependabot working.

[ahrtr]

@ahrtr Why do you assume Renovate has the same limitation? And then conclude there would be no benefit? This requires proper research.

Note that I did not say "Renovate has the same limitation". The point is it doesn't make much sense to spend too much time to investigate Renovate, because,

• dependabot can meet almost all the requirements so far;
• we have lots of higher priority tasks.

@ahrtr @sanmai-NL is there anything left to do here? We have dependabot working.

I think we can close this ticket.

[serathius]

Sounds good, the summary we were able make dependabot work for us and don't see benefits of migrating to Renovate.

[sanmai-NL]

@serathius

don't see benefits of migrating to Renovate.

Uhm, that's quite a leap. @ahrtr stated he didn't even research it. The benefits I expressed. No need to research it anyway.

You guys just chose the first tech that came to mind and decided to stick with it. Fine, not rational but fine.