Repository navigation
ci(dependabot): group the families that are only correct in lockstep - #46
Nicolas0315 wants to merge 2 commits into
Conversation
Two dependency families in this repo cannot be bumped one PR at a time, and both have been failing silently for about two months. `github/codeql-action/init` and `github/codeql-action/analyze` are two entry points of one action repository. The CodeQL runner refuses a mismatched pair, so whichever half Dependabot opens first is red: Loaded a configuration file for version '4.37.1', but running version '4.37.0' Every bump from 4.37.1 through 4.38.0 (ten of them, 2026-07-17 to 2026-09-10) failed with that error, on both Analyze jobs, and none could merge because the `main` ruleset gates on code scanning. The workflows are consequently still pinned to 4.37.0. `@vitest/coverage-v8` pins its runner peer to the exact vitest version rather than a range (4.1.10 declares `"vitest": "4.1.10"`), so a split bump of that pair is unsatisfiable by construction. `@vitest/eslint-plugin` is deliberately left out of the group: it versions independently and peers on `vitest: "*"`. Raise the npm `open-pull-requests-limit` in the same change. The default is 5, exactly five npm PRs have been open since 2026-07-13, and Dependabot has opened none since, so catalog updates are not queued behind the cap, they stop being proposed at all. That raise is only safe with the groups in place, which is why it lands here rather than on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
Warning Review limit reachedNext included review available in 36 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository: arkorlab/haru/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: arkorlab/haru/.coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🔇 Additional comments (1)
WalkthroughThe Dependabot configuration now groups coupled Vitest and CodeQL Action updates. The npm ecosystem also permits up to 20 open update pull requests. ChangesDependabot grouping configuration
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review BotNo reviewable code changes were analyzed. |
|
There was a problem hiding this comment.
All reported issues were addressed across 1 file
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
Two notes after opening this. The required checks are unrun. This is a fork PR, so The sibling repo has the same gap, now filed as arkorlab/arkor#304 and fixed in arkorlab/arkor#305. There the pairs that arkorlab/arkor#282 consolidated by hand (vitest/coverage-v8, vite/plugin-react, react/react-dom, tailwindcss/@tailwindcss/vite) are already open and split again in the 2026-09-18 batch, because the consolidation landed but the config that produced the split did not change. The arkor side carries five families rather than two, but it is the same change in the same shape, including the If you would rather this repo waited on whatever shape arkor settles on, say so and I will park this PR instead of it drifting. Edited to point at arkorlab/arkor#305, which did not exist when this was written. |
`applies-to` is a per-group key that defaults to `version-updates`, so the groups added in the previous commit left security updates ungrouped: a CVE against one half of a lockstep pair would open its own PR and recreate the mismatch the groups exist to prevent. Security updates are exempt from the cooldown, so that PR arrives immediately. Add a parallel `applies-to: security-updates` group per family. This narrows the hole rather than closing it, and the file says so: a grouped security PR carries only the members that actually have a fix available, so an advisory against one half alone still produces a one-sided bump. What the security group removes is the case where both halves are advised and would otherwise arrive as two mismatched PRs. Reported by cubic (P2). Verified against the Dependabot options reference (`applies-to` defaults to version updates, accepts `security-updates`) and the grouped-security-updates documentation (grouped security PRs bundle dependencies that have security fixes available). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two dependency families in this repo cannot be bumped one PR at a time. Both have been failing quietly for about two months, so this adds a
groupsentry for each, with the evidence for the coupling written next to it in the config.github/codeql-action/init+/analyzeThese are two entry points of one action repository, and the CodeQL runner refuses a mismatched pair. Dependabot opens them as separate PRs, so whichever half is looked at first is red:
This is not a one-off. Every codeql-action bump from 4.37.1 through 4.38.0 failed this way, on both
Analyze (actions)andAnalyze (javascript-typescript):I checked the logs at both ends of that range (the 4.37.1 run and the 4.38.0 run behind #44 / #45): same error, same cause, only the version pair differs. Because the
mainruleset gates on code scanning, none of the ten could merge, which is why the workflows are still pinned to 4.37.0 and why #44 and #45 are sitting red right now. TheCIlane passed on all ten, so the only thing standing between this repo and a current CodeQL action is the split.This is the same failure the sibling repo hit and documented in arkorlab/arkor#282 (fifth row of its pair table), where it was resolved by hand rather than at the source.
vitest+@vitest/coverage-v8@vitest/coverage-v8pins its runner peer to the exact vitest version, not a range. From the installed copy at the catalog version:So a split bump of that pair is unsatisfiable by construction: whichever half lands first leaves the pair mismatched until the other follows. arkorlab/arkor#282 saw the concrete symptom on its own 5.0.0 bump ("Vitest rejects a mixed-major core/provider pair during coverage init").
@vitest/eslint-pluginis deliberately not in this group. It versions independently (1.6.x) and its peer isvitest: "*", so it is free to move alone, and #10 should stay a standalone PR.Families I checked and left alone
I did not group by convenience, only where the manifests prove the coupling:
drizzle-orm+drizzle-kitlooks like a pair, but drizzle-kit 0.31.10 declares no peer on drizzle-orm (it bundles its own toolchain). No evidence, so no group.oxlint+oxlint-tsgolint:oxlint-tsgolint@0.24.0declarespeerDependencies: {}. Same conclusion.eslintwith wide ranges, not pins.If any of those have a coupling the manifests do not express, say so and I will add them with the reason.
The npm PR limit
One extra line, and I will drop it if you would rather keep this PR to groups alone. The npm entry is on the default
open-pull-requests-limit: 5, exactly five npm PRs have been open since 2026-07-13 (#3, #8, #9, #10, #11), and Dependabot has opened none since. That is not a queue behind a cap: at the cap it stops proposing, so the catalog has had no update pressure for two months.Raising it is only safe with the groups, since an uncapped ungrouped queue is what produced the 47-PR backlog in arkorlab/arkor#282. I set 20 rather than arkor's 100 to match this repo's much smaller catalog; happy to change the number.
Verification
.github/dependabot.yamlis not reachable by any test, so what I could check, I checked:yamlcatalog entry, keys match the Dependabot schema)pnpm install --frozen-lockfilepnpm format:checkpnpm buildpnpm typecheckpnpm lintFound 0 warnings and 0 errorsper packagepnpm testdb:generateclean,git status --porcelain packages/db/drizzleemptyRun on Node 24.18.0 / pnpm 11.10.0.
What I cannot verify from here is Dependabot actually honouring
groupsagainstcatalog:entries inpnpm-workspace.yaml. Group matching is documented per ecosystem and by dependency name, and the pnpm-catalog support already resolves these names, so it should hold, but the first real proof is the next codeql-action or vitest release. The codeql-action group is independent of that question, since actions are not catalog-resolved.Notes
🤖 Generated with Claude Code
Summary by cubic
Groups two dependency families that must move in lockstep and raises the npm PR limit so catalog updates are proposed again. Adds parallel security-update groups so security advisories can't recreate the same mismatched PRs.
vitestand@vitest/coverage-v8are one version-update group;@vitest/coverage-v8pins the exactvitestversion.github/codeql-action/initandgithub/codeql-action/analyzeare one version-update group; every bump from 4.37.1 through 4.38.0 failed because the runner rejected a mismatched pair.applies-to: security-updatesgroup;applies-todefaults to version updates, and a grouped security PR only bundles members with fixes, so one-sided advisories still open one-sided bumps.@vitest/eslint-pluginstays out of both Vitest groups; it versions independently and peers onvitest: "*".open-pull-requests-limitis raised from 5 to 20; at the cap Dependabot stops proposing updates, which is why none had opened since 2026-07-13.Written for commit 882870b. Summary will update on new commits.
Summary by CodeRabbit