Dependency and CI automation

Open Dependency & CI updates → repository → Automation settings. Updates, project directories, and security preferences have separate tabs. Enable dependency updates and choose one or more project directories. . selects root project manifests; child projects are explicit. For shared workspace lockfiles, include the root and each child whose manifests should be updated (use Auto for children that inherit a lockfile). Dependency scans use the repository's existing daily/weekly/monthly QStash schedule and can be queued manually.

Each repository groups all available dependency updates across its selected directories and managers into one PR, including major upgrades. Subsequent scans refresh the same autopilot/dependencies/all-dependencies branch while its PR is open. This follows Renovate's all-dependencies grouping. Existing individual dependency PRs are not combined retroactively by this application change. Dependency PR descriptions follow the CI update PR style: a heading, introduction, version-change bullets with manifest paths, and an flowcy.dev footer. Update warnings remain visible; the default scanner branding and configuration controls are omitted.

Supported update managers: Node.js (Bun, npm, Yarn, pnpm), Go modules, SwiftPM (Package.swift), and Python requirements, pipenv, Poetry, PEP 621 and uv. Auto detects the manager from committed manifests/lockfiles. An explicit Node choice requires its lockfile; it does not convert the repository to a different manager. Private registries requiring additional credentials are not configured by this feature. Swift Xcode-only projects without Package.swift are not update targets.

Dependency updates are off initially. Vulnerability scans and account email notifications are on by default. Adding a repository or opening its automation page while signed in associates the account email used for background delivery. Previously added repositories need one visit to capture their account email. CI security runs independently of whether an outdated action exists. Actions pinned to SHAs or moving tags are matched to release tags (up to 500 tags); unresolved refs appear as incomplete scans, not clean results. Dependency security uses OSV-Scanner against committed lockfiles/manifests in the selected directories. Missing or unsupported inputs are reported. Findings are not proof that every dependency is safe.

New findings are deduplicated per repository, package, version, advisory and path. They are recorded before dependency updates. Email uses existing notification quotas; failed notifications remain eligible for the next scan. Full results are in Dependencies & security.

Auto-merge is off by default, independently for CI and dependency PRs. Enable it on GitHub too and configure required checks/reviews. CI uses enablePullRequestAutoMerge; dependency PRs use Renovate's artifact checks and GitHub platform auto-merge. No direct merge fallback is used by the CI integration. Incomplete dependency security scans disable auto-merge for that run. Settings do not retroactively cancel auto-merge on existing PRs.

Deployment

Repair dependency CI failures

Automation settings → Updates → Use AI to remove incompatible updates when dependency CI fails is enabled when dependency automation is enabled, and can be switched off independently. The existing /api/github/webhook receiver handles signed workflow_run.completed failures for the scanner's grouped dependency branch. Subscribe the GitHub App to Workflow run events and grant Actions: read, Contents: write, and Pull requests: write. GITHUB_WEBHOOK_SECRET, CI_UPDATE_MODEL_NAME (the dedicated CI repair model), and an eligible account with available AI sessions are required. Apply migration 0038_tiny_shriek.sql before deployment. CI repair does not fall back to the shared MODEL_NAME setting. Set CI_UPDATE_MODEL_NAME to your chosen AI Gateway model ID; token usage records the model used for that diagnosis.

Each diagnosis creates a dedicated AI SDK ToolLoopAgent in lib/agent/ci-repair.ts. It first calls readFailureEvidence, then submits its decision through the finishCiRepair tool. That tool has no execute function, so it returns control to the repair workflow without modifying the repository. The caller requires exactly one valid finish call after reading the evidence, validates all package names against the PR inventory, and rejects plain-text completion. The agent has a four-step limit and a sixty-second deadline; usage includes every model step. This follows the AI SDK completion-tool pattern, using the stepCountIs API available in this repository's installed SDK v6.

The repair agent reads failed job logs and the PR diff, then chooses a minimal set of incompatible upgrades to exclude. Renovate rebuilds the same grouped PR and lockfiles from the base branch, retaining the other upgrades. It never changes application code or weakens CI. For example, a TypeScript 7 upgrade rejected by typescript-eslint can be held back while unrelated updates remain. Package exclusions apply across selected directories for the lifetime of that open PR, including later scheduled/manual scans; they expire when the PR closes. Closing the PR and starting a new scan allows a fresh attempt.

Only PRs recorded in scanner history qualify. Stale commit failures, forks, successful or cancelled runs, and other branches are ignored. Redeliveries and multiple failing workflows share one diagnosis per head SHA, with at most three attempts per PR. Scans and repairs share the repository lease; busy repairs retry through Workflow. The PR head and settings are checked again before updating. An inconclusive diagnosis leaves the branch alone and surfaces a failure in dependency history and the agent session. The agent session records its decision and token usage. A new commit is recorded as updated, with CI still pending; GitHub's required checks/reviews continue to gate merging.

Local verification uses the documented GitHub payload/REST shapes in postman/mocks/github-automation and real Octokit HTTP calls. The model decision and Vercel Sandbox are mocked. It does not establish live model quality, webhook delivery, Renovate branch/lockfile regeneration, or successful checks on a real PR. Hosted Postman webhook capture requires postman login and was unavailable during implementation. Include lib/dependency-updates/ci-repair.test.ts in the simulation test command below.

Publish a scanner version

With Docker Desktop running and Vercel CLI logged in (vercel login and vercel link):

# Build, smoke-test, push v1.0.0 and verify it in a real Vercel Sandbox:
bun run scanner:publish 1.0.0
 
# Publish the next version and update the app's image setting after verification:
bun run scanner:publish 1.0.1 --configure production,preview

The default destination is vcr.vercel.com/rxlab/github-pm/dependency-scanner. Override it with --scope <team-slug> --project <project-slug>. Versions must be new; existing tags are rejected. Builds always target Linux amd64, using the pinned Renovate and OSV base images in the Dockerfile. Update those digests there when upgrading tools, then publish a new version. The script waits for Vercel image preparation and requires a successful live smoke-test marker even if the CLI incorrectly returns exit code zero for a failed remote command.

--configure writes the verified digest to DEPENDENCY_SANDBOX_IMAGE; it does not redeploy the application. Redeploy through the normal release process afterward. A failed build, push, or smoke test leaves deployment settings unchanged. An image published before a failed smoke test remains in VCR for diagnosis; use a new version for the corrected image. This does not test repository updates or PR creation.

The image's Renovate wrapper removes Sandbox's conflicting NODE_USE_SYSTEM_CA selector while retaining NODE_EXTRA_CA_CERTS and normal TLS certificate validation.

Test the publishing flow locally without network access: node --test scripts/publish-dependency-scanner.test.mjs.

Application setup

1. Apply db/migrations/0037_graceful_silver_samurai.sql with the normal migration flow.
2. Build infrastructure/dependency-scanner/Dockerfile using reviewed, digest-pinned ghcr.io/renovatebot/renovate full and ghcr.io/google/osv-scanner images as RENOVATE_IMAGE and OSV_IMAGE. Use OSV-Scanner 2.4+ for Swift Package.resolved support and Renovate 44.176.2 or later for the manager configuration validated here. Publish the image to the deployment's Vercel Container Registry.
3. Set DEPENDENCY_SANDBOX_IMAGE to that VCR image's digest-pinned reference. It must provide Containerbase for dynamic tool version installation, git, renovate, osv-scanner, Node/Bun/npm/Yarn/pnpm, Go, Python, pipenv/Poetry/uv on PATH. Verify their versions in the image before enabling scans. The app does not build or publish the image automatically.
4. Use Vercel OIDC for Sandbox authentication in production. Outside Vercel, supply VERCEL_TOKEN, VERCEL_TEAM_ID, and VERCEL_PROJECT_ID.
5. Existing QStash and Workflow setup must be active. Dependency VMs have a ten-minute limit; the Workflow step has an 800-second budget (requires an eligible Vercel plan). One repository scan holds a fifteen-minute lease. Interrupted runs are marked failed when a subsequent scan acquires the expired lease.

The scanner ignores repository Renovate configuration and uses controlled manager/path rules. Install scripts/plugins and arbitrary post-upgrade commands are disabled. Each VM is ephemeral and stopped in finally. Manifests and lockfiles are resolved remotely; repository tooling never runs on the web application host.

Contracts and checks

Authenticated server actions: getRepositoryAutomation(id), saveRepositoryAutomation(id, settings) (strict Zod schema), and triggerDependencyScan(id) (queues a durable workflow). All enforce installation ownership. Existing QStash signatures protect scheduled entry points. There is no new public REST endpoint. Settings and scan histories use dedicated tables.

Manual dependency scans create a queued history entry before Workflow dispatch. The worker updates that same entry to running and then completed or needs attention; dispatch failures and busy workers stay visible in history. No schema migration is needed for the queued status. Scans that failed before this change created no entry and must be triggered again after deployment.

patches/@vercel%[email protected] guards the SDK's stdin retry configuration when Workflow strips step methods from serialized classes in its VM bundle. Normal Node execution retains both methods and their zero-retry settings. Keep this Bun patch until the upstream SDK/Workflow combination handles those assignments. Run node --test scripts/dependency-workflow.test.mjs to compile the real scan workflow and verify VM initialization and manual/scheduled step dispatch.

Tests cover configuration scope, access isolation, notification retries, concurrent leases, scan failures and GitHub native auto-merge. The local Postman GitHub simulation uses the published Octokit/GitHub API response shapes, not an owner's hosted mock (Postman login was unavailable). It exercises real Octokit HTTP calls without creating PRs.

Run the local integration simulation with:

postman simulation run postman/simulations/github-automation.sim.yaml --port 4909 --output ndjson
GITHUB_AUTOMATION_SIMULATION_URL=http://127.0.0.1:4909/github bunx vitest run lib/dependency-updates/github-simulation.test.ts lib/dependency-updates/ci-repair.test.ts

Provider references: Vercel Sandbox SDK, Renovate manager configuration, OSV output contract, GitHub native auto-merge.

Successful dependency CI repairs comment on the PR with the diagnosis, held-back packages, replacement commit and failed workflow link. The comment explicitly says CI is pending. Duplicate deliveries for the same head do not post again. A comment permission or delivery failure leaves the repair recorded as applied and adds a warning to dependency history.