ci: switch from dependabot to renovate

[nielspardon]

We are currently using dependabot which has a very limited feature set, for example it can not handle managing a pixi.lock file as demonstrated in https://github.com/substrait-io/substrait/actions/runs/25411815587/job/74535026421?pr=1072

Renovate is also free to use and a much more powerful dependency auto update tool compared to dependabot. It can handle pixi.lock files out of the box among other things like e.g. it could also be used to update Git submodules to tags instead of just the latest commit (https://docs.renovatebot.com/modules/manager/git-submodules/#updating-to-specific-tag-values).

It gives a more flexibility and helps to address the issue with dependabot not handling the pixi.lock file properly.

• Adds a renovate.json config file configuring semantic commits as the commit style for Renovate and the commit type as build and scope as deps to match the dependabot style following: https://docs.renovatebot.com/configuration-options/#semanticcommitscope
• Removes the dependabot.yml configuration file to disable dependabot.
• Modifies the commitlint ignore patterns to include a pattern for renovate PRs.
• Replaces chore: Configure Renovate #1074

---

This change is 

[benbellick]

Thanks @nielspardon. Can we include a description in the PR body for why we should switch from dependabot to renovate? I think it has something to do with how dependabot interacts with pixi but it would be great to have it in writing somewhere so we can reference it in the future if something comes up. Thank you!

[nielspardon]

updated the description. let me know if the description looks good for you.

[benbellick]

Is this comment still relevant if we no longer use dependabot?

[benbellick]

Is there a way to validate that this works before merging?

[nielspardon]

I've been testing this on my private fork and I found that the current pixi support for Renovate is only covering the direct Pixi dependencies in [tool.pixi.dependencies] e.g. NodeJS which when it does update the version also updates the pixi.lock file: https://github.com/nielspardon/substrait/pull/5/changes

When it updates one of the dependencies in the dev dependency group in [dependency-groups] it does not update those using the Pixi manager and Renovate thus also not updating the pixi.lock file currently: https://github.com/nielspardon/substrait/pull/7/changes

[nielspardon]

I logged a feature request with Renovate to help us fix this gap: renovatebot/renovate#43260

[nielspardon]

FYI: Renovate also supports postUpgradeTasks if you are hosting it yourself. When using the hosted one with the Github App it does not allow custom commands for security reasons.

[benbellick]

Thanks for investigating. Hopefully we can figure out something that will work for our setup.

[nielspardon]

I opened a PR to fix renovate for pixi lock file updates: renovatebot/renovate#44004

[tokoko]

do we need dependency groups? in our case, what's the difference between dependencies and a dev dependency group? isn't the whole thing a single dev environment anyway?

[nielspardon]

maybe we should discuss this in a separate issue. feels unrelated to switching from dependabot to renovate.

[tokoko]

yeah, just a possible shortcut 😆 doesn't really matter though if the issue is being addressed in renovate anyway

[nielspardon]

The issue with Renovate is not caused by the dependencies being in a dependency group. We would have the same issue if they were regular Python dependencies in [project.dependencies] in pyproject.toml. The issue is that the pixi support in Renovate today would only update the pixi.lock file when suggesting a dependency update in pixi.toml or in [tool.pixi.dependencies] in pyproject.toml. This is better than dependabot which has no pixi support at all but wouldn't help since we are using pyproject.toml in this repo and no pixi.toml.

The PR I opened in Renovate which got one approval already makes sure the pixi.lock file gets updated when Python dependencies in pyproject.toml (outside of [tool.pixi.dependencies]) get bumped including dependency groups.

Whether we should declare the dependencies as project dependencies or in a dev dependency group is orthogonal in my opinion.