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

@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
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 pull request needs a /compile comment
before it can go green. Worse, every merge to a target branch invalidates the
committed assets on all the other open pull requests, so a backlog of N bumps
is up to N sequential rebase/compile/merge cycles rather than N compiles.
There are 14 open Dependabot pull requests, 9 against main and 5 against
stable34.

Grouping, by class of update:

- npm-production and npm-development split the direct dependencies, so a
  bundle regression narrows to one half rather than needing a bisect across
  everything in a single pull request, each attempt costing a /compile.
  Majors stay ungrouped on main so they still get individual review; on
  stable34 the existing ignore rule already limits updates to patches.

- npm-security is separate because a group applies only to version updates
  unless applies-to says otherwise. That matters here more than it looks:
  npm indirect dependencies are not covered by version updates at all, so
  they reach us solely as security updates. Those are exactly the bundled
  runtime bumps that need a /compile — immutable, fast-uri, postcss, axios
  and dompurify have all arrived that way — and security updates are also
  exempt from open-pull-requests-limit, so nothing else in this file bounds
  them. Grouping them is the change with the most effect on /compile cycles.

- The composer groups set group-by: dependency-name because grouping is
  otherwise per-directory, which would still produce one pull request per
  vendor-bin/* tool.

Also disable automatic rebasing for npm. A rebase without a recompile leaves
CI red regardless, so rebasing every open pull request on each merge only
burns CI runs across the whole queue. This disables Dependabot's automatic
rebasing only; a manual @dependabot rebase still works, which is what the
/compile flow relies on. Two caveats worth recording: the option covers
security updates as well as version updates, and pull requests opened before
it lands keep being rebased until 30 days after they were opened, so the
saving arrives gradually rather than at once. Composer keeps auto-rebase,
since those pull requests pass without a recompile.

The cooldown is mostly alignment with nextcloud/server rather than a lever in
its own right: Dependabot already applies a default 3-day cooldown to version
updates, and never applies one to security updates.

The stable34 schedule is offset by thirty minutes so the two branch queues do
not land simultaneously and stale each other's assets.

On precedent: nextcloud/server has the same committed-build-output
constraint, and rebase-strategy: "disabled" on npm ("without a build CI will
likely fail anyway") and cooldown are taken from its configuration. Its
grouping is deliberately narrower — three tool-family patterns, no catch-all,
composer ungrouped — because its npm churn concentrates in eslint, vite and
vitest. Office's does not, so family patterns would barely reduce the count
here. The broader grouping is this repository's own call rather than
something server endorses.

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 0b80c0d to e2883d1 Compare August 17, 2026 14:54
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