Configure dependabot to automated version updates

[daniel-zullo-frequenz]

Add dependabot configuration file to automate version updates for pip dependencies and github actions.

The security updates needs to be checked/enabled from the settings in the repo.

Fixes: #242

[leandro-lucarella-frequenz]

Do you have any examples of how this work in your fork to understand better how it works?

A few other questions:

1. Will this propose only security updates or will also propose updates when any dependency gets a new version released?
2. If it is the second, will propose updates only for minor updates? Major too? IIRC there were options to control this.
3. Will this run on all branches or just the default branch? If the second, can it be enabled to older versions also can get security updates?

[daniel-zullo-frequenz]

Do you have any examples of how this work in your fork to understand better how it works?

Yes, you can see some PR examples here

[daniel-zullo-frequenz]

Will this propose only security updates or will also propose updates when any dependency gets a new version released?

The securities update are managed/configured in the settings of the repo, see image below. We only need to ensure/check security updates are enabled

The configuration file will take care only of version updates

[daniel-zullo-frequenz]

Will this run on all branches or just the default branch? If the second, can it be enabled to older versions also can get security updates?

The current configuration will run only on the default branch. Though we can set manually another branch using target-branch

[daniel-zullo-frequenz]

Added the supported branches so that security updates are automatically applied on those branches. Unfortunately I couldn't use anchor and aliases in the YAML for dependabot as they not supported due to security issues with the yaml parser for some ecosystems. Thus you might notice there are code duplication/redundancy in the configuration

[leandro-lucarella-frequenz]

The securities update are managed/configured in the settings of the repo, see image below. We only need to ensure/check security updates are enabled

I see, so we have no control over security updates? Like frequency, labels, etc? I thought there was some config possible with the yaml file.

[leandro-lucarella-frequenz]

The current configuration will run only on the default branch. Though we can set manually another branch using target-branch

Do you know if we can use wildcards? I would enable it for all branches. We can just remove unmaintained branches so they don't get PRs, this will clearly indicate which branches are maintained and which aren't anymore.

[leandro-lucarella-frequenz]

Yes, you can see some PR examples here

A few comments:

• I see all those PRs have prio:urgent, is this because you configured it like this in your test repo?

• So mainly all updates are breaking except 2 right? I see major versions are being updated. I repeat the question, can we configure if we want to do patch, minor or major updates, or all? If all, is it possible to have 3 separate PRs, as the patch and minor should normally succeed and the major break?

  OK, actually for libs I guess patch and minor updates makes no sense, and we'll test them anyway and is only the minor requirements, so we probably don't want to bump them unnecessarily. But for apps it probably makes sense to try all of them (and separately).

• Is it possible to configure unstable versions (0.x.x) to consider minor updates as breaking too, so as major updates? Or if this is the default?

[daniel-zullo-frequenz]

Do you know if we can use wildcards? I would enable it for all branches. We can just remove unmaintained branches so they don't get PRs, this will clearly indicate which branches are maintained and which aren't anymore.

I'm afraid we cannot use wildcards either in the current state :(
There are feature-requests to add support for yaml aliases and wildcards, or support multiple target-branches given a one update-configuration but at the moment we might need to live with the code duplication if we use dependabot

[daniel-zullo-frequenz]

I see all those PRs have prio:urgent, is this because you configured it like this in your test repo?

No, that was because I accidentally set version updates for stable branches (non-default) instead of only security updates.

Is it possible to configure unstable versions (0.x.x) to consider minor updates as breaking too, so as major updates? Or if this is the default?

I'm afraid we cannot configure that or I haven´t found it yet how to do it. Anyway let's please discuss it in a call

[leandro-lucarella-frequenz]

OK, we met and here is the summary of what we talked about:

• There is a lot of documentation lacking for dependabot, which makes it hard to know how it will work. This might be a reason to look for alternatives eventually, but we'll still try dependabot for now because of the easy integration.
• About libraries vs apps, we couldn't find any source of truth, but we ended up assuming that if a dependency is specified as a range, then probably dependabot will just widen the dependency and if it is pinned, it will update the pinning.
• We decided to pin all dev dependencies to a particular version, as we don't really need to support a range. This will maximize the reproducibility of builds and dependabot will let us know when there are new versions of the dependencies so we can easily bump them.
• We decide to remove all hacks to support branches other the default branch. For now we only get updates in the default branch and we'll manually backport anything that we deem important.
• The configuration file is only for maintenance bumping of dependencies. Security updates are handled in the repo config (it is already enabled) and can't be configured any further.

[daniel-zullo-frequenz]

Thanks Luca for the nice write up!
I've updated the PR to remove the security updates hack on supported branches and to pin dev/test dependencies to a particular version.

[leandro-lucarella-frequenz]

Excellent!

Last comment (optional): We don't really need to set the reviewers here, as we already have it in the CODEOWNERS file, it's sort of redundant.

[daniel-zullo-frequenz]

We don't really need to set the reviewers here, as we already have it in the CODEOWNERS file, it's sort of redundant.

I agree and I've already removed reviewers.