Skip to content

ci(dependabot): group the families that are only correct in lockstep - #46

Open
Nicolas0315 wants to merge 2 commits into
arkorlab:mainfrom
Nicolas0315:fix/dependabot-lockstep-groups
Open

Nicolas0315 wants to merge 2 commits into
arkorlab:mainfrom
Nicolas0315:fix/dependabot-lockstep-groups

Conversation

@Nicolas0315

@Nicolas0315 Nicolas0315 commented Sep 19, 2026 •

Copy link
Copy Markdown

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 groups entry for each, with the evidence for the coupling written next to it in the config.

github/codeql-action/init + /analyze

These 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:

##[error]Loaded a configuration file for version '4.37.1', but running version '4.37.0'
##[error]analyze post-action step failed: Loaded a configuration file for version '4.37.1', but running version '4.37.0'

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) and Analyze (javascript-typescript):

Bump Date CI CodeQL Advanced
4.37.1 2026-07-17 success failure
4.37.2 2026-07-22 success failure
4.37.3 2026-07-23 success failure
4.37.4 2026-07-31 success failure
4.37.5 2026-08-04 success failure
4.37.6 2026-08-05 success failure
4.37.7 2026-08-14 success failure
4.37.8 2026-08-24 success failure
4.37.9 2026-08-27 success failure
4.38.0 2026-09-10 success failure

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 main ruleset 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. The CI lane 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-v8 pins its runner peer to the exact vitest version, not a range. From the installed copy at the catalog version:

"peerDependencies": { "@vitest/browser": "4.1.10", "vitest": "4.1.10" }

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-plugin is deliberately not in this group. It versions independently (1.6.x) and its peer is vitest: "*", 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-kit looks 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.0 declares peerDependencies: {}. Same conclusion.
  • The eslint plugin family peers on eslint with 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.yaml is not reachable by any test, so what I could check, I checked:

Step Result
YAML parses to the expected structure clean (parsed with the repo's own yaml catalog entry, keys match the Dependabot schema)
pnpm install --frozen-lockfile clean
pnpm format:check 145 files, clean (oxfmt excludes yaml; run to prove nothing else moved)
pnpm build 7/7
pnpm typecheck 12/12
pnpm lint 12/12, Found 0 warnings and 0 errors per package
pnpm test 12/12 tasks, 30 test files
Migration drift gate db:generate clean, git status --porcelain packages/db/drizzle empty
No em dash (U+2014) clean

Run on Node 24.18.0 / pnpm 11.10.0.

What I cannot verify from here is Dependabot actually honouring groups against catalog: entries in pnpm-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.

  • vitest and @vitest/coverage-v8 are one version-update group; @vitest/coverage-v8 pins the exact vitest version.
  • github/codeql-action/init and github/codeql-action/analyze are one version-update group; every bump from 4.37.1 through 4.38.0 failed because the runner rejected a mismatched pair.
  • Each family also gets an applies-to: security-updates group; applies-to defaults to version updates, and a grouped security PR only bundles members with fixes, so one-sided advisories still open one-sided bumps.
  • @vitest/eslint-plugin stays out of both Vitest groups; it versions independently and peers on vitest: "*".
  • npm open-pull-requests-limit is raised from 5 to 20; at the cap Dependabot stops proposing updates, which is why none had opened since 2026-07-13.
  • The cap raise is safe only alongside the groups, which keep lockstep families from being split into unsatisfiable PRs.

Written for commit 882870b. Summary will update on new commits.

Review in cubic

Summary by CodeRabbit

  • Chores
    • Dependabot now groups related Vitest and CodeQL Action updates into single pull requests.
    • Up to 20 npm dependency update pull requests can remain open simultaneously.

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>
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

@coderabbitai

coderabbitai Bot commented Sep 19, 2026 •

Copy link
Copy Markdown

Review Change StackReview Change Stack

Warning

Review limit reached

Next included review available in 36 minutes.

Check out review usage here.

View limit details

Limit 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.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: arkorlab/haru/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: c5f42688-54a3-406b-8640-41211f47427e

📥 Commits

Reviewing files that changed from the base of the PR and between c85ad00 and 882870b.

📒 Files selected for processing (1)
  • .github/dependabot.yaml

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository: arkorlab/haru/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 6d2cb0f6-0e94-47f6-ace0-fbc9e9ea5e3c

📥 Commits

Reviewing files that changed from the base of the PR and between 9bf0062 and c85ad00.

📒 Files selected for processing (1)
  • .github/dependabot.yaml

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)
  • GitHub Check: cubic · AI code reviewer
  • GitHub Check: Seer Code Review
🔇 Additional comments (1)
.github/dependabot.yaml (1)

8-13: LGTM!

Also applies to: 26-42, 56-67


Walkthrough

The Dependabot configuration now groups coupled Vitest and CodeQL Action updates. The npm ecosystem also permits up to 20 open update pull requests.

Changes

Dependabot grouping configuration

Layer / File(s) Summary
npm update grouping and limit
.github/dependabot.yaml
The npm ecosystem limit increases to 20. The vitest group matches vitest and @vitest/coverage-v8.
GitHub Actions update grouping
.github/dependabot.yaml
The codeql-action group matches github/codeql-action*, grouping its action entry points into one update pull request.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Other

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the Dependabot configuration change and explains that dependency families will be grouped when they must update in lockstep.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
✨ Simplify code
  • Create a new PR

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@drift-check

drift-check Bot commented Sep 19, 2026

Copy link
Copy Markdown

Code Review Bot

No reviewable code changes were analyzed. ⚠️ The documentation drift check could not be evaluated. Reviewed 0 file(s); skipped 1.

@greptile-apps

greptile-apps Bot commented Sep 19, 2026 •

Copy link
Copy Markdown

RetriggerConfidence Score: 5/5

The Dependabot configuration appears safe to merge.

Summary

Adds Dependabot groups for dependency families that must be updated together.

  • Groups vitest with @vitest/coverage-v8 for version and security updates.
  • Groups CodeQL action usage for version and security updates.
  • Raises the npm open-pull-request limit from 5 to 20.
  • Documents the rationale and residual limitation of grouped security updates.

Reviews (2) · Last reviewed commit: "ci(dependabot): cover the security lane ..."

@cubic-dev-ai cubic-dev-ai Bot left a comment •

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 1 file

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread .github/dependabot.yaml
@Nicolas0315

Nicolas0315 commented Sep 19, 2026 •

Copy link
Copy Markdown
Author

Two notes after opening this.

The required checks are unrun. This is a fork PR, so check and test-postgres are sitting at action_required and need the fork workflows authorized before the ruleset can go green. The same is true of #33 and #34. The verification table in the description was produced by running both lanes locally against this exact head (Node 24.18.0, pnpm 11.10.0, real postgres:17 container for the integration lane), but that is evidence, not a substitute for the checks.

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 applies-to correction below, so reviewing either one covers most of the other.

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>
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