ci(dependabot): group minor and patch updates, disable npm auto-rebase - #95
Open
moodyjmz wants to merge 1 commit into
Open
ci(dependabot): group minor and patch updates, disable npm auto-rebase#95moodyjmz wants to merge 1 commit into
moodyjmz wants to merge 1 commit into
Conversation
moodyjmz
force-pushed
the
ci/group-dependabot-updates
branch
from
August 3, 2026 14:24
c8d00f9 to
0b80c0d
Compare
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
force-pushed
the
ci/group-dependabot-updates
branch
from
August 17, 2026 14:54
0b80c0d to
e2883d1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
js/build output is committed, andnpm-build.ymlfails 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 onstable34), oldest from 2026-07-04, with four ungrouped ecosystem/branch blocks each atopen-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.ymlis 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:
npm-productiondependenciesnpm-developmentdevDependenciesnpm-otherdependency-typedoesn't cover indirect deps for npmThat third group is doing more work than it looks.
dependency-typeapplies 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
mainare transitive —immutable(#80),fast-uri(#81),postcss(#93) andaxios(#94, transitive because the manifest declares@nextcloud/axios) — anddompurifyin #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
mainso they keep arriving individually for review. Onstable34the existingignorerule already limits updates to patches, so those groups need noupdate-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-strategydoes not appear in the current Dependabot options reference, and I have not verified that a manual@dependabot rebasecomment 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
ignoreentry, 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/servercommits itsdist/output and uses this same combination —groups,rebase-strategy: "disabled"on npm, andcooldown.Notes
🤖 Generated with Claude Code