Switch from dependabot to rennovate

[vredchenko]

question - if we have dependabot on github - how come we use renovate? Are they not more or less the same
tools?
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
✦ While Dependabot and Renovate serve the same high-level purpose (detecting out-of-date dependencies and opening
Pull Requests), they are like comparing a "stock car" to a "highly customized racing rig."

In the context of DiamondLightSource, the move to Renovate in modern repos like blueapi is a clear sign of
increasing DevOps maturity. Here is why an organization would choose Renovate over GitHub's built-in Dependabot:

1. Grouping (The "PR Noise" Problem)

• Dependabot: By default, it opens one PR per dependency update. If you have 20 outdated Python packages, you
  get 20 PRs. This often leads to "notification fatigue," where developers start ignoring them.
• Renovate: It is famous for Grouping. You can tell Renovate: "Put all minor boto3 and aws updates into a single
  'AWS Updates' PR." This significantly reduces the burden on human reviewers.

2. "Automerge" Capabilities

• Dependabot: Does not natively support automerging (though you can hack it with GitHub Actions).
• Renovate: It has a robust "Automerge" feature. You can configure it so that if a patch-level update passes all
  your CI tests (unit tests, linting, etc.), Renovate will automatically merge the PR without a human ever
  touching it. This is the ultimate "Shift-Left" goal: keeping the repo secure and up-to-date with zero manual
  effort.

3. Support for "Niche" Ecosystems

• Dependabot: Focuses on the most popular languages (JS, Python, Go, Ruby).
• Renovate: Supports a much wider array of "infrastructure as code" (IaC) tools. At a facility like Diamond
  Light Source, you likely use:
  • Helm Charts (Kubernetes)
  • Dockerfiles with specific base image digests
  • Conda/Mamba environments
  • Pre-commit hooks themselves!
  • Renovate is much better at tracking these "non-standard" scientific and infrastructure dependencies than
    Dependabot.

4. Configuration Granularity

• Dependabot: Configuration is relatively simple and limited (check frequency, ignore list).
• Renovate: Has a massive JSON schema. You can set different rules for different teams, schedule updates for
  "off-peak" hours (e.g., only on Tuesday mornings), and even write custom "Regex Managers" to track versions in
  files that Renovate doesn't natively understand (like a custom scientific config file).

5. Cross-Platform Consistency
   If Diamond Light Source ever uses GitLab or an On-Premise Bitbucket for internal/sensitive projects, Dependabot
   (which is GitHub-exclusive) won't work there. Renovate is platform-agnostic, meaning the DLS teams can use the
   exact same security configuration whether the code is on GitHub or an internal server.

In Summary: Why DLS uses Renovate
The teams at Diamond Light Source using Renovate (like the Bluesky team) are likely doing so to reduce the
"maintenance tax" of their complex scientific software stack. They want fewer, smarter PRs and the ability to
automate the "boring" updates so they can focus on the science.

Dependabot is "Good Enough" for a simple library; Renovate is for "Mission-Critical Infrastructure."