[fernandolins]

What

• Change dependabot interval from monthly to quarterly for all ecosystems (Cargo, npm, Python, GitHub Actions)
• Add separate groups for major bumps (rust-major, npm-major, python-major) so they arrive as a single grouped PR instead of individual ones
• Add semver-major-days: 30 cooldown for major bumps on all versioned ecosystems

Why

Version update PRs were accumulating faster than the team could review them. Two issues were causing this:

1. Minor/patch grouped PRs were opened monthly. Try moving it to quarterly may match the actual review cadence better
2. Major bumps fell outside the minor/patch group and opened as individual PRs per package, adding noise

Security updates are unaffected: they still open immediately regardless of the schedule, as they bypass the interval setting by design.

[ianoff]

LGTM

[iamllama]

👍 for grouping minor/patch updates, but major updates can come with breaking changes that might be better handled in a separate pr per crate/package (e.g. #4105 and fabric)?

[fernandolins]

@iamllama I agree with you. My goal isn't to merge Dependabot's major version PRs, but rather to reduce the noise caused by having a separate PR for each major update.
When we want to merge a major bump, we should create a new PR with the relevant changes.

Thoughts?

[Luc-Mcgrady]

My goal isn't to merge Dependabot's major version PRs, but rather to reduce the noise caused by having a separate PR for each major update.

I don't understand. Would this cause more noise with both the dependabot's pr which you wont merge + the individual PR's.

If you mean that we should bump all major versions at the same time then that's probably a bad idea there are some major versions which take a lot of effort like #2566. This should probably be reviewed separately and also the other major updates would be held back by that.

[iamllama]

I understood as it using dependabot major update prs as a sort of notification instead of actually merging them, unless mistaken?

[david-allison]

Security updates are unaffected: they still open immediately regardless of the schedule, as they bypass the interval setting by design.

AFAIU, this is not the case for GitHub Actions. Vulns are not alerted and now could go unnoticed for up to 3 months.

Alerts for GHA were disabled here:

• chore(ci):Use commit SHAs for github actions #4916

There was a comment regarding security, but it doesn't seem to match the docs: AFAIU Dependabot security alerts do not work on SHA-pinned actions, but do work for tagged actions.

Dependabot alerts don't cover GitHub Actions at all (regardless of SHA or tag pinning), but Dependabot version updates will still open PRs to bump the SHAs when new versions are released.
So this approach works well.

-- #4916 (comment)

---

But from the GitHub docs:

For GitHub Actions, alerts are only generated for actions that use semantic versioning, not SHA versioning.

-- https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts#limitations:~:text=For%20GitHub%20Actions%2C%20alerts%20are%20only%20generated%20for%20actions%20that%20use%20semantic%20versioning%2C%20not%20SHA%20versioning.

[Luc-Mcgrady]

I understood as it using dependabot major update prs as a sort of notification instead of actually merging them, unless mistaken?

I think that if the objective of this PR is to decrease the noise caused by dependabot then having it create PR's that will never be merged seems counter-productive to me.

As I see it, currently dependabot ignores major bumps so there is no noise created.

... but rather to reduce the noise caused by having a separate PR for each major update.
When we want to merge a major bump, we should create a new PR with the relevant changes.

I interpreted this as possibly meaning that he doesn't think we should have separate (non dependabot) pr's for major updates which seems bad to me. If a new pr is created for each major update anyway then it wouldn't decrease the noise? Although I suppose it would reduce the noise associated with dependabot constantly opening and closing pr's. Maybe I misunderstood.

[iamllama]

As I see it, currently dependabot ignores major bumps so there is no noise created.

#4941, #5005 and #5193 are major update prs? But i agree with not grouping major updates as they are uncommon and can be modified as needed (e.g. #5002)

[fernandolins]

Our current behavior:
Major updates are handled individually, so Dependabot opens a major PR whenever necessary.

Security Updates are also handled individually. The Dependabot configuration does not prevent security update PRs from being opened whenever needed.

What I proposed was:
Grouping major updates for notification purposes only.
However, we should handle each one individually in separate PRs.
(Alternatively, we can keep things as they are; we will simply continue to receive multiple Dependabot PRs that remain unresolved in the short term).

I don't understand. Would this cause more noise with both the dependabot's pr which you won't merge + the individual PR's.
I think that if the objective of this PR is to decrease the noise caused by dependabot then having it create PR's that will never be merged seems counter-productive to me.
As I see it, currently dependabot ignores major bumps so there is no noise created.

@Luc-Mcgrady I understand your point, but today it's already a bit counter-productive, since we have a major update PR that hasn't been updated in months (Fabric for example). At least for now, we have several open PRs that rarely anyone is working on due to the heavy workload involved, the need to ensure compatibility, priorities, and so on.

Just a correction: when it's not written what to do with major updates in the Dependabot configuration, it understands that it should open a PR whenever necessary for major bumps.
(As I said, we can keep this behavior)

he doesn't think we should have separate (non dependabot) pr's for major updates which seems bad to me.

No, what I tried to avoid is having multiple PRs for Major updates from Dependabot only, but I'm in favor of analyzing which dependencies are in this PR and then creating individual PRs to work on each dependency. But these new PRs will only be opened when someone explicitly works on them.

Let's assume we have 5 major updates: fabric, myst-parser, and 3 others.

We can have 5 PR from Dependabot or just 1.
If we have 5, we can choose one to work with. And the other 4 will be left open without anyone looking.

If we have 1, we choose which lib we want to update and then create 1 more PR with the updates.
(total of 2 PR against 5 in the previous case)

@david-allison you have a good point about SHA-pinned actions. But here we have a trade-off: SHA pinning prevents tag-based supply chain attacks at the cost of losing Dependabot security alerts (it was a choice we made)

[Luc-Mcgrady]

Sounds good to me.