Add dependabot config

[AllSeeingEyeTolledEweSew]

This lets github's dependabot auto-update our github actions, via auto-generated PRs.

On my fork, it generated the following PRs:

• https://github.com/AllSeeingEyeTolledEweSew/libtorrent/pull/44
• https://github.com/AllSeeingEyeTolledEweSew/libtorrent/pull/45
• https://github.com/AllSeeingEyeTolledEweSew/libtorrent/pull/46
• https://github.com/AllSeeingEyeTolledEweSew/libtorrent/pull/47

I believe this change needs to be in the default branch (RC_2_0) to be effective. Once there, dependabot be enabled automatically, and will start generating PRs like the above. However you may need to manually enable it: go to Settings > Code Security and Analysis > Dependabot Security Updates > Enable.

Dependabot can manage other package ecosystems like pypi. For the places where we do pip install in a github action, I believe we'd need to use separate requirements files like pip install -r requirements-for-this-action.txt, and dependabot would manage the requirements files. We can experiment with this later.

[arvidn]

it's not obvious to me that this is a net benefit. is there a problem with using checkout@v2? I don't think so, and once there is, it can be updated manually.

The question is, which is more common:

1. There's a problem in CI that's resolved by bumping the version of some action
2. There's a new version of some action that dependabot will generate a PR for

[AllSeeingEyeTolledEweSew]

In general, I argue for proactively upgrading dependencies, for several reasons.

There are the usual arguments, such as picking up bugfixes and security updates. Microsoft bills dependabot as a security feature.

If we reactively wait to upgrade until a use case breaks, then we have to upgrade while the use case is broken, which is just always riskier than upgrading before it's broken. I claim proactive upgrades mitigate our risk.

Moreover, in practice I find that upgrades are like earthquakes: if they get delayed, they're more impactful when they happen. There's a pathology that a well-written dependency may work a long time, until its own dependency ecosystem starts to fail. At that point, upgrading the dependency means upgrading an ecosystem. Again, better done before our use case is broken than after.

The counterpoint to the all the above is the risk of introducing new bugs with each update. But I claim if a dependency update introduces a bug and our tests don't catch it, then the fault is with our tests, not with the update. I recognize this is a philosophical take, but CI itself is a philosophical take, my claim is that automatic updates are an essential part of CI.

Specifically with dependabot, we can automate and configure a lot. We can auto-merge dependabot's PRs if CI passes.

We can also ignore semver-major updates in hopes to only pick up bugfixes, though to my mind this ~~defeats~~ weakens the purpose.

[AllSeeingEyeTolledEweSew]

It might also be nice to combine dependabot with pinning exact versions.

Instead of

uses: actions/checkout@v3

we do

uses: actions/[email protected]

When v3.0.1 is released, dependabot will generate a PR like

--- uses: actions/[email protected]
+++ uses: actions/[email protected]

This way, we can always test new package releases with our CI. We could be more confident that when we test code changes, we're only testing the changes we think we're testing.

[stale[bot]]

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

[AllSeeingEyeTolledEweSew]

Thoughts?

[arvidn]

But I claim if a dependency update introduces a bug and our tests don't catch it, then the fault is with our tests, not with the update

I agree with this when it comes to regular dependencies. But that's not what this is about. This is about the programs that run the tests. A bug at this level might cause the tests not to run at all, and just always be green. I don't think it's reasonable for libtorrent to have tests to ensure the CI platform itself is working.

So, I don't really have a strong opinion here, I'm just not quite sold on the benefit. What's the value of a bugfix for a feature we don't use? Or maybe we're somehow relying on an existing bug, so a bugfix would really break the workflow.

[AllSeeingEyeTolledEweSew]

Or maybe we're somehow relying on an existing bug, so a bugfix would really break the workflow.

That's reason enough to me to justify dependabot :) If it doesn't justify it to you, then we probably have irreconcilable views on this.

[stale[bot]]

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

[AllSeeingEyeTolledEweSew]

@arvidn ping

[stale[bot]]

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