Skip to content

ci(dependabot): group minor and patch updates, disable npm auto-rebase - #95

Open
moodyjmz wants to merge 1 commit into
mainfrom
ci/group-dependabot-updates
Open

ci(dependabot): group minor and patch updates, disable npm auto-rebase#95
moodyjmz wants to merge 1 commit into
mainfrom
ci/group-dependabot-updates

Conversation

@moodyjmz

@moodyjmz moodyjmz commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Problem

js/ build output is committed, and npm-build.yml fails if the working tree is dirty after a build. So any bundled-dependency bump makes the committed assets stale and turns the PR red until someone comments /compile.

The per-PR cost is the small part. Every merge to a target branch invalidates the committed assets on every other open PR, so a backlog of N bumps isn't N compiles — it's up to N sequential rebase → /compile → merge cycles, because each merge stales the rest. Merging #82 immediately staled the others.

There are currently 17 open Dependabot PRs (11 on main, 6 on stable34), oldest from 2026-07-04, with four ungrouped ecosystem/branch blocks each at open-pull-requests-limit: 10.

Automating the compile isn't the fix: GitHub deliberately restricts tokens on Dependabot-triggered runs so a malicious dependency can't exfiltrate secrets, which is exactly why command-compile.yml is comment-triggered behind a permission check. The lever available is reducing the number of PRs.

Changes

Grouping

Each npm block gets three groups. Groups are first-match, so order matters:

Group Catches Why
npm-production direct dependencies bundle regression narrows to the runtime half
npm-development direct devDependencies tooling churn kept separate from the bundle
npm-other everything else — i.e. transitive dependency-type doesn't cover indirect deps for npm

That third group is doing more work than it looks. dependency-type applies to direct dependencies only, and npm isn't among the ecosystems where it extends to indirect ones, so a production/development split alone would leave transitive bumps arriving as individual PRs — "any outdated dependencies that do not match a rule are updated in individual pull requests."

That's not a marginal case. Four of the ten currently open npm PRs on main are transitive — immutable (#80), fast-uri (#81), postcss (#93) and axios (#94, transitive because the manifest declares @nextcloud/axios) — and dompurify in #82 was as well. Those bundled transitive runtime deps are precisely the ones that need a /compile, so omitting the catch-all would have left the most expensive class of PR untouched.

Majors stay ungrouped on main so they keep arriving individually for review. On stable34 the existing ignore rule already limits updates to patches, so those groups need no update-types.

Auto-rebase and cooldown

rebase-strategy: "disabled" on the npm blocks. A rebase without a recompile leaves CI red regardless, so auto-rebasing every open PR on each merge just burns CI runs across the whole queue. Composer keeps auto-rebase — those PRs pass without a recompile.

To be transparent about the evidence here: this mirrors nextcloud/server, which sets the same option with the comment "Disable automatic rebasing because without a build CI will likely fail anyway". However, rebase-strategy does not appear in the current Dependabot options reference, and I have not verified that a manual @dependabot rebase comment still works while it is disabled. Since the rebase → /compile → merge recipe depends on manual rebasing, that's worth confirming on the first grouped PR. Happy to drop this hunk and land the grouping alone if maintainers would rather not take it on trust.

cooldown (4 days, 8 for majors) so rapid successive releases of the same dependency collapse into one update instead of one PR each. Cooldown applies to version updates only — security updates are explicitly not delayed by it.

Trade-off worth stating

Grouping introduces head-of-line blocking: one bad dependency now blocks its whole group, where previously seven of eight PRs could merge independently. The production/development split limits the blast radius, and an offender can be pulled out with an ignore entry, but it is a genuine cost rather than a free win.

Grouping also shortens the merge-order treadmill rather than eliminating it — each merge still stales the remaining open PRs. The point is that it's a handful of cycles a week instead of seventeen.

Precedent

nextcloud/server commits its dist/ output and uses this same combination — groups, rebase-strategy: "disabled" on npm, and cooldown.

Notes

  • Config only; no effect until Dependabot next evaluates the schedule (Saturdays 03:00 Europe/Paris).
  • Worth merging before clearing the existing backlog, otherwise the merge-order cycle gets paid ~16 more times and Saturday's run rebuilds the queue anyway.
  • Existing open PRs aren't retroactively grouped — Dependabot will supersede them with grouped PRs as it re-evaluates, or they can be merged/closed as usual.

🤖 Generated with Claude Code

The js/ build output is committed, and npm-build.yml fails when the working
tree is dirty after a build. Every bundled-dependency bump therefore makes
the committed assets stale, and the PR needs a /compile comment before it
can go green.

That cost is per-PR, and worse, every merge to a target branch invalidates
the committed assets on all the other open PRs — so a backlog of N bumps is
up to N sequential rebase/compile/merge cycles rather than N compiles. There
are currently 17 open dependabot PRs across main and stable34.

Group minor and patch updates so a week of bumps arrives as a handful of PRs
rather than one per dependency. Each npm block gets three groups, and since
groups are first-match the order matters:

- npm-production and npm-development split direct dependencies, so a bundle
  regression is narrowed to one half rather than requiring a bisect across
  every dependency in a single PR, each attempt costing a /compile.

- npm-other then catches everything the first two cannot. dependency-type
  covers direct dependencies only, and npm is not one of the ecosystems for
  which it extends to indirect ones, so without this group transitive bumps
  would keep arriving as individual PRs. That is not a marginal case: four of
  the ten currently open npm PRs on main are transitive (immutable, fast-uri,
  postcss, and axios, the last because the manifest declares
  @nextcloud/axios), and dompurify in #82 was too. Those bundled transitive
  runtime dependencies are exactly the ones that need a /compile.

Majors stay ungrouped on main so they still get individual review; on
stable34 the existing ignore rule already limits updates to patches.

Also disable auto-rebase for npm. A rebase without a recompile leaves CI red
regardless, so rebasing every open PR on each merge only burns CI runs across
the whole queue. Composer keeps auto-rebase, since those PRs pass without a
recompile.

Adds a cooldown so rapid successive releases of the same dependency collapse
into one update rather than one PR each. Cooldown applies to version updates
only, so security updates are not delayed.

This mirrors nextcloud/server, which commits its dist/ output and uses the
same combination of groups, disabled npm rebasing and cooldown for the same
reason.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: James Manuel <moodyjmz@users.noreply.github.com>
@moodyjmz
moodyjmz force-pushed the ci/group-dependabot-updates branch from c8d00f9 to 0b80c0d Compare August 3, 2026 14:24
@moodyjmz
moodyjmz requested a review from emberfiend August 3, 2026 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant