Skip to main content

Renovate Autoupdater

We use Renovate to keep dependencies up to date, and a custom Renovate Upgrade Validation workflow that runs on every Renovate PR. When the upgrade passes all quality checks, the PR is auto-merged. When it fails (or is a major bump), we spawn a Cursor Cloud Agent to analyze the changelog, fix the codebase, and merge once green. At the time of writing, this pipeline has merged 40+ dependency updates and spawned at least 10 agents to fix breaking changes or failing checks.

Why automate dependency upgrades?

  • Security and fixes — Patches and minors land quickly without manual PR review.
  • Consistency — One workflow: parse PR → run checks → merge or spawn agent.
  • Agent handoff — When checks fail or policy requires review, the Cursor agent gets the PR URL, failed check logs, and the renovate-upgrade-validation skill so it can fix and merge.

Tools in place

ComponentPurpose
renovate.jsonRenovate config: rebase when behind, labels, automerge rules (patch/minor for deps and devDeps; major = no automerge, label major-upgrade). Mongoose is disabled for AdminJS compatibility.
.github/workflows/renovate-validate.ymlRuns on Renovate PRs (open/sync/reopen). Parses the PR, runs the full quality gate, then either auto-merges or spawns a Cursor agent.
scripts/parse-renovate-pr.mjsExtracts upgraded package names and version ranges from the PR title/body for the workflow and agent.
.cursor/skills/renovate-upgrade-validation.mdSkill the agent follows: research changelog, audit usage, apply fixes, run gate, approve and merge or request human review.

High-level flow

Success path (no agent)

When the upgrade is patch/minor and nothing breaks:

  1. Renovate opens the PR (or updates it).
  2. renovate-validate runs: checkout, pnpm install, parse PR, run typecheck → lint → test → e2e → cycles → contract tests → contract coverage → build → docs build.
  3. All checks pass and the upgrade is not major → workflow posts the impact analysis as a PR comment, approves the PR, and runs gh pr merge --squash --auto.
  4. Renovate’s automerge (or platform merge) completes. No agent is used.

Fail path → agent spawn

When any check fails or the upgrade is major:

  1. The workflow runs the same steps but does not auto-merge.
  2. It posts a PR comment with the analysis and “Checks failed” or “Agent required by policy (major-update-policy)”.
  3. It calls the Cursor Cloud Agent API with a prompt that includes: PR title, branch, failed checks, error log excerpts, upgraded packages (from the parser), and instructions to follow the renovate-upgrade-validation skill.
  4. The agent checks out the branch, researches changelogs, audits usage, applies fixes, and re-runs the full gate. It may take several iterations.
  5. If the agent gets everything green: it posts a summary comment, approves the PR, and runs gh pr merge --squash --auto.
  6. If the agent is still blocked after a bounded number of iterations: it posts a comment explaining what’s broken and what was tried, and requests human review.

Concurrency and thundering herd

The workflow uses a single concurrency group (renovate-upgrade-validation-agent-merge) with cancel-in-progress: false, so only one validation run (and at most one agent spawn) proceeds at a time. That avoids multiple agents merging different PRs in a conflicting order.

We also had to lower Renovate’s effective concurrency: at one point Renovate opened several dependency PRs at once (e.g. five ESLint-related updates). Each failed and spawned an agent; multiple agents then made similar ESLint config fixes in parallel, which was wasteful and could conflict. We addressed this by:

  • Relying on the workflow’s concurrency group so only one validation/agent runs at a time.
  • Optionally tightening Renovate’s PR concurrency (e.g. prConcurrentLimit in renovate.json) so fewer PRs are open at once, reducing the chance of many agents being spawned for similar tooling upgrades.

Keeping one active validation run and one agent at a time keeps the pipeline predictable and avoids duplicate work.

What gets tested

The same gate runs in the workflow and in the agent’s loop:

CheckCommand
typecheckpnpm typecheck
lintpnpm lint
testpnpm test
e2epnpm e2e (with Mongo + local auth env)
cyclespnpm check:cycles
contract testspnpm test:contracts
contract coveragepnpm check:contracts-coverage
buildpnpm build
docs buildpnpm docs:build

Branch protection can require “CI / build-test” and “CI / semgrep” (and others); the workflow waits for required PR checks before deciding to merge or spawn.

At a glance

  • 40+ merges — Most patch/minor PRs pass the gate and are auto-merged by the workflow.
  • 10+ agents spawned — When checks fail or the upgrade is major, the Cursor agent runs the skill, fixes the code, and merges or escalates.
  • One validation at a time — Concurrency group prevents overlapping agent runs and merge races.
  • Single skill — All agent behavior is defined in renovate-upgrade-validation.md so humans and the API-invoked agent follow the same process.

For the exact steps the agent takes (changelog research, usage audit, fix patterns, merge criteria), see the renovate-upgrade-validation skill (listed in the Reference) and the workflow file .github/workflows/renovate-validate.yml.